# Retries and recovery (/docs/retries)



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 [#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:

```ts title="eventlayer.ts · server only"
import { Eventlayer } from "eventlayer";

const eventlayer = new Eventlayer(undefined, { maxRetries: 0 });
```

This still reads `EVENTLAYER_KEY` from your environment. See the
[SDK](/docs/sdk) for configuration and [rate limits](/docs/rate-limits) for `429` responses.

## Recover according to the operation [#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                            |
| Create an attendee with a ticket | Both are saved together; reconcile a lost response before submitting again   |
| 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 [#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. A retry can create another
registration even when the first response was lost.

<DocsLinks
  items="[
{ title: &#x22;Build a registration flow&#x22;, description: &#x22;Create an attendee and ticket together.&#x22;, href: &#x22;/docs/guides/website-registration&#x22; },
{ title: &#x22;React to ticket changes&#x22;, description: &#x22;Verify, persist and deduplicate incoming webhooks.&#x22;, href: &#x22;/docs/guides/webhooks&#x22; },
]"
/>