- This section describes endpoints defined in Operator.
- Operator produces the webhook endpoints.
- Provider consumes them.
/result, /rollback, and /tournamentresult webhooks must be idempotent.- Within each webhook scope, you may receive the same request with the same
betId multiple times but with different uniqueId. This is as per the retry policy from provider.
- In that case, operator must ensure idempotency. Within each separate webhook, multiple requests with the same
betId must be processed only once.
- When Provider calls webhook on Operator, the Operator must respond in a timely manner.
- Timeout limit is 1 second for
/bet webhook, and 5 seconds for other webhooks.
- For
/bet webhook, in case the Operator fails to respond within this time limit, the bet will be rolled back with /rollback webhook.
- For
/result, /rollback, and /tournamentresult webhooks; in case the Operator fails to respond within this time limit, Provider will retry again later according to the retry policy below.
- Idempotent webhooks must retain their idempotency even with retries.
- Only applicable to certain webhooks:
/result, /rollback, and /tournamentresult.
- When Provider calls a webhook on Operator, the Operator might fail to respond within timeout limit.
- In that case, Provider retries to call the webhook on the Operator using the same request parameters excluding
uniqueId which is unique per request-response pair.
- Provider retries up to 10 times after the initial timed-out request.
- First retry is after 10 seconds. Second retry is after 30 seconds. Third retry is after 120 seconds. Then 600 seconds, 1800 seconds, and so on until reaching 86400 seconds for the 10th and final retry.
- This retry policy may change in the future; in that case, this section will be updated accordingly.
- With each webhook request, there's a property
uniqueId. Please ensure the exact value is returned in the root of webhook response body.