Skip to main content
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:
​
string
required
One of accepted, draft, published, rejected.
​
string
Your identifier for the stored content. Up to 256 characters.
​
string
HTTPS URL of the stored content. Up to 2048 characters.
​
string
Your version identifier for the stored content. Up to 128 characters.
​
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

​
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 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: 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.