The customerIdentifier is the reseller’s unique identifier of the customer. This is shared with Bango, but not with the merchant – unless contractually agreed between reseller and merchant.

The entitlementId field is the globally unique identifier for a single entitlement. Bango generate this identifier.

Bango generates the bangoUserId that is shared between the reseller and the merchant for a specific customer.
It’s a generic identifier and not route specific.

Bango generates the sharedCustomerId that is shared between the reseller and the merchant for a specific customer.
It’s route specific, so one customerId will have multiple sharedCustomerIds if the customer has multiple entitlements with different merchants.

By default the reseller is responsible for performing eligibility checks on the customer before the request is sent to Bango. As an example, if a reseller determines a customer is only eligible for one free trial per customer, they should implement an eligibility check at the time of purchasing the subscription, if the customer is not eligible the reseller may want to allow the user to sign-up for the non-free trial product.

In the majority of cases, yes. The customerIdentifier is the reseller’s unique identifier of the customer. This is shared with Bango, but not with the merchant – unless specifically requested that it is. Bango generates a route specific id for the customer for each entitlement they purchase with a different merchant. This is the sharedCustomerId.

202 is associated with asynchronous flows, signalling the request has been received, validated and is in progress (e.g. accepted). 200 is a final response confirming the request was processed successfully and is used in synchronous flows.

No, the bangoUserId will vary for a single user on different reseller platforms.

Use the Report API to understand what has been created for a particular customerIdentifier.

Use the Get an Entitlement API to retrieve specific details on the entitlement.

Using the header is optional.

A 404 error will be returned.

PATCH can be used by both merchants and resellers to update the product key and metadata of the entitlement. Resellers can also use the PATCH endpoint to set an expiry date on the entitlement for Bango to manage the termination.

The Bango DVM™ does not require it but we can support it for inbound requests.

No, if you want to find out the activation URL then you should use the ‘Request activation info’ API.

The x-request-id and x-operation-id parameters are limited to 255 characters.

Yes, and it should be application/json for all requests with a body.

The status returned will directly reflect the status of the entitlement on the Bango platform at the time of the request.

Yes, if the URL is wrong.

Bango can support credential rotation. Please highlight this as a requirement during your integration.

No, merchantExtensionData is designed to be private data – specifically not shared with the Reseller.

No, extensionData is designed to be private data for the Reseller – specifically not shared with the Merchant.