Webhooks

Use our webhooks to be notified if something changes in e-guma.

Our webhooks try to call the endpoint you provide 3 times until we get a response with the HttpStatusCode being in the Successful range (200-299).

To set up a webhook, please send your webhook URL, webhook information and account to [email protected].

Request headers

Every webhook request is sent as an HTTP POST with a JSON body and contains the following headers:

Header	Description
`Content-Type`	Always `application/json`
`X-Eguma-Webhook-Topic`	The event that triggered the webhook, e.g. `voucher_order.created` (see Topics)
`X-Eguma-Idempotency-Key`	A unique key (GUID) identifying this delivery. All retries of the same delivery carry the same key.

Topics

The X-Eguma-Webhook-Topic header follows the scheme entity.event and can have one of the following values:

Topic	Sent when	Details
`voucher.redeemed`	A voucher is redeemed	Redeem Webhook
`voucher_order.created`	A voucher order is created	Voucher order created Webhook
`voucher_type.created`	A voucher type is created	Voucher type created Webhook
`voucher_type.updated`	A voucher type is updated	Voucher type updated Webhook
`voucher_type.deleted`	A voucher type is deleted	Voucher type deleted Webhook
`ticket_order.created`	A ticket order is created	Ticket order created Webhook
`newsletter.opt_in_confirmed`	A newsletter double opt-in is confirmed	Newsletter Double Opt-In Webhook

Handling duplicates (idempotency)

A webhook may reach your endpoint more than once — for example when your endpoint responds with a non-successful status code and we retry, or when a failed delivery is re-sent manually by our support team. All of these repetitions carry the same X-Eguma-Idempotency-Key.

To process each event exactly once, store the idempotency keys you have already processed and ignore any request whose key you have seen before. Requests with a key you have not seen yet are always new events and must be processed.

Responding to a webhook

Respond with an HTTP status code in the range 200-299 as quickly as possible — ideally acknowledge first and do any heavy processing asynchronously. Any other status code (or a timeout) counts as a failed attempt and triggers a retry, up to 3 attempts in total.