Skip to Main Content

Mock Response Headers

Mock Response Headers

When sending a request to Bango, you can use a mock response header to specify which response you want returned so that you can test all happy path variations without needing multiple downstream routes configured.

To use mock response headers, add “X-Magic-Number” as a header in your request along with the value required based on your request and desired response.

For example, if you want to send a create entitlement request and wish to simulate the merchant responding with 202 and an activation url, you would add this header to your request:

X-Magic-Number example

Bango supports different values depending on the endpoint being used. You can find a list of supported values and how they effect the entitlement’s state below.

We provide 3 mock response headers to simulate the 3 possible happy path responses from the merchant:

  • CREATE_REQUEST_RETURNS_ACTIVATION_REQUIRED
    Response code: 202
    Response body contains the parameters json block containing a fake activation url
    The entitlement’s status is PENDING
    The entitlement’s dateCreated has been set
  • CREATE_REQUEST_RETURNS_CREATED
    Response code: 201
    The entitlement’s status is PENDING
    The entitlement’s dateCreated has been set
  • CREATE_REQUEST_RETURNS_ACTIVATED
    Response code: 200
    The entitlement’s status is ACTIVE
    The entitlement’s dateCreated has been set as well as dateActivated

We provide 2 mock response headers to simulate the 2 possible happy path responses from the merchant:

  • ACTIVATION_INFO_RETURNS_ACTIVATION_URL
    Response code: 200
    Response body contains the parameters json block containing a fake activation url
  • ACTIVATION_INFO_RETURNS_ACTIVATION_CODE
    Response code: 200
    Response body contains the activation code parameter with a fake activation code

For updates that don’t get sent to the merchant (e.g. updating the notificationUrl), you do not need to provide a mock response header. The entitlement is updated within Bango and you will receive a happy path response regardless.

For requests that are sent on to the merchant (e.g. productKey change), we provide 2 mock response headers to simulate the 2 happy path responses:

  • UPDATE_RETURNS_UPDATED
    Response code: 200
    Response body will show the updated parameters
  • UPDATE_RETURNS_ACCEPTED
    Response code: 202
    Response body will show the original parameters as the merchant has not yet confirmed the update end-to-end

We provide 3 mock response headers to simulate the 3 possible happy path responses from the merchant:

  • TERMINATE_RETURNS_TERMINATED
    Response code: 200
    The entitlement’s status is CANCELLED
    The entitlement’s dateEnded has been set
  • TERMINATE_RETURNS_ACCEPTED_FUTURE_DATE
    Response code: 200
    The entitlement’s status is ACTIVE-ENDING
    The entitlement’s dateEnded has been set (with a future date)
  • TERMINATE_RETURNS_ACCEPTED_NO_DATE
    Response code: 202
    The entitlement’s status is ACTIVE

We provide 2 mock response headers to simulate the 2 possible happy path responses from the merchant:

  • TERMINATE_RETURNS_TERMINATED
    Response code: 200
    The entitlement’s status is REVOKED
    The entitlement’s dateEnded has been set
  • TERMINATE_RETURNS_ACCEPTED_NO_DATE
    Response code: 202
    The entitlement’s status is ACTIVE