> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bilt.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Handle rejections and resends

> Read why Bilt rejected or held an order event, fix it, and resend it safely

Bilt checks every event a few seconds after it answers `202`, and the check can end in a rejection or a hold.

## Before you begin

* [Send order events](/partners/order-reporting/send-order-events.md) to staging and get `202` responses.
* Keep the `webhook-id`, the body, and the `idempotencyKey` of every request you send, so you can resend it unchanged.
* Agree with your Bilt integration manager how you get rejection reports. A self-serve lookup is planned and not available yet.

## How it works

Every event ends `ACCEPTED`, `HELD`, or `REJECTED`, and a held or rejected event carries one reason. A held event waits for something that has not arrived yet, and Bilt checks it again by itself. A rejected event is final, so you fix the event and send it as a new request.

```mermaid theme={null}
flowchart LR
    A[You POST an event] --> B[202 Accepted]
    B --> C{Bilt checks it}
    C -->|ACCEPTED| D[Recorded]
    C -->|HELD| E[Bilt waits for the missing data, then checks again]
    C -->|REJECTED| F[You fix it and send a new request]
```

## Steps

**1. Read the reason**

Ask your Bilt integration manager for the result, giving the `webhook-id`. Look up the reason in the [order report reasons](/partners/errors-and-retries.md#order-report-reasons) table.

**2. Leave held events alone**

Do not resend a `HELD` event. Bilt checks it again once the `PURCHASE`, the card `AUTHORIZED`, the card `CAPTURED`, or the customer's account link arrives.

**3. Fix a rejected event**

Every other reason is yours to fix, except `PARTNER_DISABLED`, which Bilt fixes. Change the event, give it a new `idempotencyKey`, and send it with a new `webhook-id`.

**4. Retry a request that did not get a 202**

After a timeout or a `500`, send the same `webhook-id` with exactly the same body. Sign it again with the current time. Bilt ignores the copy if it already has the request.

**5. Resend a request that failed the signature check**

Bilt never processed it. Fix the key, the clock, or the signed bytes, and send it again. See [Sign your requests](/partners/order-reporting/sign-your-requests.md).

> [!WARNING]
>
> **Never send a different body with a `webhook-id` you already used.** Bilt rejects it with `IDEMPOTENCY_KEY_REUSED`, and the first request does not change.

## What can go wrong

* You change the body on a retry. Bilt rejects it with [`IDEMPOTENCY_KEY_REUSED`](/partners/errors-and-retries#order-report-reasons).
* You resend an accepted `orderId` or `returnId` with another body. Bilt rejects it with [`ORDER_CONFLICT`](/partners/errors-and-retries#order-report-reasons).
* A card capture arrives before its authorization. Bilt holds it with [`AUTHORIZATION_NOT_FOUND`](/partners/errors-and-retries#order-report-reasons) until the authorization lands.
* The customer never links. The event stays held with [`CONSUMER_NOT_LINKED`](/partners/errors-and-retries#order-report-reasons).

## Next steps

* [Errors and retries](/partners/errors-and-retries.md) lists every reason and what to do about it.
* [Test and go live](/partners/test-and-go-live.md) has the staging test plan for order reporting.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.