Skip to main content

Idempotency

Svix supports idempotency for safely retrying requests without accidentally performing the same operation twice. This is useful when an API call is disrupted in transit and you do not receive a response.

info

This section is about making API calls to Svix. For information on helping your customers ensure they only get a message once, please refer to receiving idempotency section (deduplication) below.

To perform an idempotent request, pass the idempotency key in the Idempotency-Key header to the request. The idempotency key should be a unique value generated by the client. You can create the key in however way you like, though we suggest using UUID v4, or any other string with enough entropy to avoid collisions.

const svix = new Svix("AUTH_TOKEN");
const message = {
eventType: "invoice.paid",
eventId: "evt_Wqb1k73rXprtTm7Qdlr38G",
payload: {
type: "invoice.paid",
id: "invoice_WF7WtCLFFtd8ubcTgboSFNql",
status: "paid",
attempt: 2,
},
};
await svix.message.create("app_Xzx8bQeOB1D1XEYmAJaRGoj0", message, {
idempotencyKey: "fd56a56b-838d-4456-8b83-390802672895",
});

Svix's idempotency works by saving the resulting status code and body of the first request made for any given idempotency key for any successful request. Subsequent requests using the same auth token and the same idempotency key will return the same result for a period of up to 12 hours.

Please note that idempotency is only supported for POST requests.

Receiving idempotency (deduplication)

Svix offers "at least once" delivery semantics. This means that if there are issues during delivery (e.g. networking issues) a message can sometimes be processed twice by the webhook receiver.

In many cases this is not a concern, and recipients can just process the duplicated requests. Though when "exactly once" semantics are required, webhook consumers can use Svix's webhook deduplication support to ensure that.

Svix includes a webhook-id header with every webhook request. That ID is unique per message but is reused across retries of the same message. Consumers can then use this identifier to ensure that they only process each event once, by for example storing the ID in redis with a 24hr expiry, and checking whether they already processed the message's webhook-id before processing it.