Eventlayer / API & operations
Retries and recovery
Distinguish a failed request from an unknown outcome before repeating a write.
A lost response does not tell you whether the server saved a change. Recovery starts with the operation you were performing and what your application knows.
SDK retry behaviour
The TypeScript SDK defaults to three retries with exponential backoff and jitter.
It retries timed-out requests and HTTP 429, 500, 502, 503 and 504
responses. The default request timeout is 30 seconds. Other network errors throw immediately.
For workflows that create attendees, tickets or other resources, disable automatic retries until your application has a recovery path:
import { Eventlayer } from "eventlayer";
const eventlayer = new Eventlayer(undefined, { maxRetries: 0 });This still reads EVENTLAYER_KEY from your environment. See the
SDK for configuration and rate limits for 429 responses.
Recover according to the operation
| Operation | After a failure or lost response |
|---|---|
| Read a resource | Retry within your timeout and rate-limit budget |
| Create an attendee or ticket | Reconcile whether it exists before creating again |
| Register an attendee, then issue a ticket | Save each returned ID and resume from the failed step |
| Check in a ticket | Treat a lost response as unknown; do not infer that your scanner admitted it |
| Receive a webhook | Deduplicate durable processing; deliveries can repeat |
Save progress in your product
Store the booking or order identity in your database, along with the returned Eventlayer resource IDs. Serialize work for the same booking. An application submission key helps prevent duplicate requests, but it cannot make your database and the remote API one transaction.
Keep unknown outcomes visible for reconciliation. Do not automatically rerun the whole registration flow when only ticket creation failed.