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

# Receipts and retries

> What your response means to Weelkit, how to claim a remote publish state, and exactly when a delivery is retried.

Weelkit interprets your endpoint's response under strict semantics: a 2xx acknowledges **delivery**, an optional typed receipt can additionally claim a remote content state, and everything else maps deterministically onto failure or retry.

## What a 2xx means

A 2xx response means exactly one thing: **the delivery was accepted**. It does *not* mean the article was published, stored, or processed remotely. Weelkit records the delivery as accepted-only unless your response body carries a valid receipt.

## Optional receipt

To claim a remote state, return a bounded JSON receipt in the 2xx response body:

```json theme={null}
{
  "status": "published",
  "remoteId": "art-1042",
  "remoteUrl": "https://blog.example.com/launch-notes",
  "remoteVersion": "3",
  "message": "Published to the news collection."
}
```

**status** `string` *required*

One of `accepted`, `draft`, `published`, `rejected`.

**remoteId** `string`

Your identifier for the stored content. Up to 256 characters.

**remoteUrl** `string`

HTTPS URL of the stored content. Up to 2048 characters.

**remoteVersion** `string`

Your version identifier for the stored content. Up to 128 characters.

**message** `string`

Human-readable note shown in the delivery log. Up to 500 characters.

Two rules govern receipts:

* A remote **draft** or **published** state is claimed **only** from a valid receipt. Weelkit never infers a publish from a bare 2xx.
* Malformed receipts, receipts violating the field bounds, and oversized response bodies (over 64 KB) are **ignored** — the delivery stays accepted-only. An invalid receipt never fails a delivery.

## Non-2xx responses

| Response | Handling |
| - | - |
| 3xx | Recorded as `failed`. Redirects are **never followed**. |
| 408, 429, 5xx | Retried on the retry ladder. |
| Other 4xx | Recorded as `failed` immediately — no retries. |

## Timeouts and network loss

Your endpoint has **10 seconds** to answer, headers and any receipt body included. If the request times out or the connection is lost **after dispatch**, Weelkit cannot know whether your endpoint received it. The attempt is recorded as `outcome_unknown` and retried under the **same** event and operation identity. An `outcome_unknown` attempt is never rewritten as `failed` — the log preserves the honest uncertainty.

Because retries reuse the operation identity, your endpoint's [deduplication](https://docs.weelkit.com/integrations/webhook/signature-verification.md#replay-protection) makes this safe: if the original attempt actually reached you, the retry is a no-op on your side and simply produces the acknowledgment Weelkit missed.

## Retry ladder

Retries follow the bounded schedule described in [Webhook setup](https://docs.weelkit.com/integrations/webhook/setup.md#retry-schedule): at most 3 automatic attempts, after at least 1 minute and then 5 minutes. A longer `Retry-After` takes precedence. Every retry reuses the same `X-Weelkit-Event-Id` and `X-Weelkit-Operation-Id`.

Inactive endpoints stop automatic dispatch and retries. A successful delivery is not sent again. When a delivery is actually retried, its current result reflects the new attempt; an earlier receipt cannot stand in for that attempt's outcome.


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