pass.* events
Time-limited pass access window lifecycle: opened, closed, cancelled, and what happened to each holder.
Time-limited pass access window lifecycle: opened, closed, cancelled, and what happened to each holder. Fires as a time-limited pass plan's scheduled access windows open, close and, when a creator postpones one, get cancelled. A pass sells access to one dated window rather than an ongoing membership, so most of these describe the window itself: use them to drive slate-level automation such as posting a line-up when access opens or a recap when it ends.
The holder_* events are the exception: each describes one buyer rather than the window. Cancelling a window resettles every buyer individually and the outcomes need different handling downstream (a move is a date change to push into a calendar or CRM, a stranding is money owed) so each holder gets its own event. holder_queued and holder_missed are the same idea applied to attendance: who is set up to be let in, and who never turned up.
If the plan is a Pass Series, the window-level events and holder_queued/holder_missed still fire for every underlying window, with the pass_series.* family firing alongside them to describe the slate. holder_moved and holder_stranded are the exception: a season-ticket holder gets pass_series.leg_substituted or pass_series.leg_dropped instead of, not alongside, those two.
For ordinary per-subscriber grants and revocations, use member.resource_added and member.resource_removed instead.
Background
What a cancellation emits
Cancelling one window produces several events in a single burst:
| Event | Fires |
|---|---|
pass.holder_moved | Once per holder who was moved (ordinary pass) |
pass_series.leg_substituted | Once per holder who was moved (season ticket) |
pass.holder_stranded | Once per holder whose pass ended (ordinary pass) |
pass_series.leg_dropped | Once per holder who lost that date (season ticket) |
pass.window_cancelled | Once, last, carrying the two tallies |
Which of each pair fires depends on what the holder bought: a single-window pass ends, whereas a season ticket loses one date and carries on.
A cancelled window never subsequently emits pass.window_opened or pass.window_closed; it is removed from the lifecycle entirely.
Timestamps are UTC
Every payload carries its window times in UTC. A pass schedule is authored in the creator's timezone, so convert before displaying: a window advertised as 9:00 AM in New York is 13:00+00:00 or 14:00+00:00 depending on daylight saving.
Example envelope
{
"id": "evt_01HX...",
"type": "pass.window_opened",
"created_at": "2026-09-20T13:00:04Z",
"api_version": "2026-05-01",
"project_id": "7f3d1c92-8b45-4e6a-9d21-5c8e0a4b6f13",
"data": {
"plan_id": "c4e82f16-93a7-4d5b-b81c-6e0f27a94d3b",
"window_id": "3d5a8c72-b016-4e94-8fa7-61c209d4e738",
"starts_at": "2026-09-20T13:00:00+00:00",
"ends_at": "2026-09-21T03:00:00+00:00",
"subscribers_affected": 47
}
}Required abilities
Tokens subscribing to a window-level event (window_scheduled, window_opened, window_closed, window_cancelled) must carry project-subscription-plan:view: a pass window belongs to the plan that sells it, so it is scoped with the plan rather than with the subscription that holds it.
The holder-level events (holder_queued, holder_moved, holder_missed, holder_stranded) describe a specific purchase and therefore require project-subscription:view instead.
Events
pass.window_scheduledA new access window came into existence on a time-limited pass plan.pass.window_openedA time-limited pass access window opened and its holders were admitted.pass.window_closedA time-limited pass access window ended and its holders were removed.pass.window_cancelledA creator cancelled a time-limited pass access window, and its holders were resettled.pass.holder_queuedA pass holder tapped their invite link and their join request is now held.pass.holder_movedA pass holder was moved from a cancelled access window to the next available one on the same plan.pass.holder_missedA window closed and one holder never turned up for it.pass.holder_strandedA pass holder's window was cancelled with no replacement available, so their pass ended and a refund is owed.pass.window_scheduled
WEBHOOKA new access window came into existence on a time-limited pass plan.
When this fires
A dated access window was created on a pass plan: either generated from the plan's recurrence, or placed by hand from Manage Access Windows or the pass windows endpoint.
This is the event that lets you mirror a schedule outward without polling for it. Every other pass.* event describes something happening to a window that already exists; this one is the window arriving.
Why this matters more once a series is involved. A Pass Series can be set to absorb new windows automatically as they are scheduled, and its holders are granted them at no charge. Without this event an integration has no way to learn a season grew except by re-reading the plan: the difference between a synced calendar and a stale one.
Caveats
- Editing a schedule regenerates windows in bulk. Saving a pass plan rebuilds its unsold future windows, so a single edit can emit this many times in quick succession. Batch on your side rather than treating each as an isolated announcement.
- Regeneration never touches a window somebody bought, a window a series points at, or one a creator pinned, so those are not deleted and re-created, and do not re-emit.
source: manualwindows are never rebuilt by a schedule edit. They fire this once, when placed.- Timestamps are UTC.
timezoneis on the payload precisely so you do not have to look the plan up to render them correctly.
Related events
pass.window_opened: the same window reaching its start time.pass.window_cancelled: a window being withdrawn.pass_series.leg_added: a rule absorbing a newly-scheduled window into a live season.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
pass.window_opened
WEBHOOKA time-limited pass access window opened and its holders were admitted.
When this fires
A scheduled access window on a time-limited pass plan reached its start time. Everyone holding that window has been admitted to the plan's resources on the connector.
Windows are processed every minute, so this fires within roughly 60 seconds of the advertised start time rather than exactly on it.
This describes the window, not an individual subscriber. For per-member grants, subscribe to
member.resource_added, which fires once per subscriber per resource.
Caveats
- Timestamps are UTC. A pass schedule is authored in the creator's timezone, so rendering these without converting will show the wrong local time to buyers.
subscribers_affectedcounts holders who were eligible at open time, not at purchase time. Cancelled and paused passes are excluded, so this can be lower than the number sold.- Anyone who buys after this fires is outside the count entirely; a plan whose sales cutoff is anchored to the window end keeps selling while the window runs. Those admissions arrive as
member.resource_added, not as a secondpass.window_opened. - A window whose worker was down for its entire span is closed without ever opening. In that case this event never fires and only
pass.window_closedis emitted.
Related events
pass.window_closed: paired transition.member.resource_added: per-subscriber grant.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
pass.window_closed
WEBHOOKA time-limited pass access window ended and its holders were removed.
When this fires
A scheduled access window reached its end time. Everyone who held it has been removed from the plan's resources on the connector. For a single-window pass that also ends the purchase: one purchase buys one window, so there is no next window to roll into. For a Pass Series holder only this date's access is stripped; the subscription ends only when the window that closed was the last date they held.
This also fires for a window that never opened because the worker was unavailable for its entire span. Such a window is closed rather than opened late, so nobody is admitted to a window that has already finished.
Caveats
- Timestamps are UTC; convert to the plan's schedule timezone before showing them.
- A subscription that this close ends also emits
subscription.expired, andmember.churnedwhen it was the subscriber's last active subscription. A series holder mid-slate emits neither, onlypass_series.leg_completed. De-duplicate if you consume several of these. - A cancelled window does not emit this event. It emits
pass.window_cancelledinstead, with per-holder detail inpass.holder_movedandpass.holder_stranded.
Related events
pass.window_opened: paired transition.member.resource_removed: per-subscriber revocation.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
pass.window_cancelled
WEBHOOKA creator cancelled a time-limited pass access window, and its holders were resettled.
When this fires
A creator cancelled a scheduled access window from Manage Access Windows or the cancel endpoint: a postponed match, a called-off session. This is never automatic: regeneration, slot edits and plan changes all leave sold windows alone, so cancelling is always a deliberate act.
By the time this fires every holder has already been resettled. Each one was either moved to the next available window on the same plan, or, when nothing suitable was left, had their pass ended and was told to ask the creator for a refund. The tallies are in the payload, and the per-holder detail arrives as pass.holder_moved and pass.holder_stranded for ordinary passes, or pass_series.leg_substituted and pass_series.leg_dropped for season-ticket holders.
Cancelling cannot be undone. The window keeps its start time permanently, so the same instant can never be re-created on that plan: schedule regeneration skips it and adding it by hand is refused.
Caveats
- Timestamps are UTC; convert to the plan's schedule timezone before showing them.
- The counts exclude holders who were paused, past due, or had already cancelled their own pass. Those are left bound to the cancelled window and are not resettled or messaged, so reconciling refunds from
refund_duealone will miss them. They also exclude season-ticket holders who lost this one date: those are resettled and messaged, and emitpass_series.leg_dropped, but are counted in neitherrebound,refund_due, norsubscribers_affected. refund_dueis a count, not a list. Consumepass.holder_strandedfor the identities and amounts; nothing in the dashboard records them durably.- No refund is issued by Subscriby. The buyer is told to contact the creator.
- Cancelling a window that is already Open evicts its holders immediately: anyone already admitted is removed from the connector's resources and their invite links stop working within seconds. They are not charged again and receive fresh links automatically when their replacement window opens.
- A cancelled window never emits
pass.window_closed.
Related events
pass.holder_moved: one per resettled holder.pass.holder_stranded: one per holder owed a refund.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
pass.holder_queued
WEBHOOKA pass holder tapped their invite link and their join request is now held.
When this fires
A holder tapped their invite link for a dated window that has not opened yet. The platform holds the join request, and Subscriby records that they are queued: they will be admitted automatically the moment the window opens, whether or not they are at their phone.
This is the moment a buyer stops being a risk, and it is the one thing about a pass that a creator can still act on beforehand.
Bought is not the same as queued. A purchase and a queued request are different events with different follow-up. Someone who bought but never tapped is relying on noticing a message on the day; someone queued needs nothing at all. Everything in the product that nudges a pass holder (the reminder ladder, the creator's roll call, the manual Send Reminders button) targets the first group and skips the second.
Caveats
- This fires per join request, not per purchase. A season-ticket holder queues separately for each of their dates, so one series purchase produces at least one of these per date they tap, often spread over weeks, because the link for the next date is sent in the message that ends the previous one. A plan with more than one gated resource produces one per resource they tap, all carrying the same
window_id. - It does not fire when someone taps a link for a window that is already open. That is an immediate admission, not a queued request, and arrives as
member.resource_added. - A holder who never taps produces no event at all. Absence is the signal; see
pass.holder_missedfor the other end of that. - Re-queuing does re-emit. The handler re-stamps the queue time and fires this event again on every join request it receives, so treat
subscription_id+window_idas the idempotency key on your side.
Related events
pass.holder_missed: a holder whose window closed without them joining.pass.window_opened: the moment held requests are approved.member.resource_added: the per-resource grant that follows.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
pass.holder_moved
WEBHOOKA pass holder was moved from a cancelled access window to the next available one on the same plan.
When this fires
One holder of a cancelled access window was moved onto another date. Fires once per resettled holder of an ordinary pass, alongside the single pass.window_cancelled for the window itself. A season-ticket holder's move emits pass_series.leg_substituted instead; the two are mutually exclusive.
The replacement is the soonest window on the same plan that is still on sale, has not started yet, and that this customer does not already hold a pass for. If the schedule has nothing future left, a window already in progress is used rather than stranding them. Every window on a plan sells for the same price, which is what makes the move an even swap rather than a substitution.
They are not charged again. If the cancelled window had not opened yet, their existing invite links stay valid for the replacement date; if they had already been admitted to a live window, that access and those links are revoked immediately and fresh links are sent when the replacement window opens.
Caveats
- Timestamps are UTC; convert to the plan's schedule timezone before showing them.
was_queuedis the field worth branching on. A queued holder keeps their place and is admitted automatically on the new date; an unqueued one still has to tap their link, and is sent it again as a button.- Nobody is moved onto a date they already hold. A customer with passes for two consecutive windows skips to the one after.
- The move is written quietly, so no
subscription.*event accompanies it. This event is the only signal. - Holders who were paused, past due, or had cancelled their own pass are not moved and emit nothing at all.
Related events
pass.window_cancelled: the window-level event, fired once.pass.holder_stranded: the other outcome, when no window was available.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
pass.holder_missed
WEBHOOKA window closed and one holder never turned up for it.
When this fires
An access window closed and a specific holder was recorded as Missed: they paid, the window ran, and they never joined.
pass.window_closed already reports an aggregate subscribers_affected, which is the wrong half for outreach. Who did not turn up is the useful question, the answer is already computed and stored per holder, and this is that answer.
Missed is a claim about the customer, so it is made carefully. A holder is only marked Missed when they were never admitted. If they bought so late that the window was effectively over before their payment cleared, the pass is settled as ended rather than missed and this event does not fire; Subscriby will not tell you a paying customer no-showed when the timing was ours. One exception runs the other way: when a window never opened at all because of a worker outage, its ungranted holders are recorded as Missed and this event fires for each of them, so treat a burst of these for a single window as an outage signal rather than as no-shows.
Caveats
join_requestedis the field worth branching on. A holder who never queued probably never saw the message; that is a reachability problem. A holder who queued and still did not appear made a choice, and chasing them the same way reads as nagging.- On a series this fires per date. Missing one date of a season affects nothing else: the rest of the slate runs as booked, so treat a single occurrence as a data point rather than a churn signal.
pass_series.completedcarries the final tally, which is the figure that actually means something. - It fires alongside
pass.window_closedfor the same window. Both are correct (one is per holder, one is the aggregate) so an endpoint subscribed to both receives one of each.
Related events
pass.holder_queued: the engagement this is the absence of.pass.window_closed: the aggregate for the same window.pass_series.leg_completed: the same close, seen as progress through a season.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
pass.holder_stranded
WEBHOOKA pass holder's window was cancelled with no replacement available, so their pass ended and a refund is owed.
When this fires
One holder of a cancelled access window could not be moved anywhere, so their pass was ended. Fires once per stranded holder of an ordinary pass, alongside the single pass.window_cancelled for the window itself. A season-ticket holder never reaches this state: cancelling one leg of a season emits pass_series.leg_dropped instead and leaves the rest of the slate intact.
They have paid for a date that is not happening and received nothing. Subscriby tells them so and asks them to contact the creator; it does not issue a refund.
This is the durable record of who is owed money. The creator's dashboard shows the refund count once, in a toast that survives a single page load, and the ended subscriptions are afterwards indistinguishable from ordinary expiries. This event carries the identity, the amount and the gateway reference, so consuming it is the only reliable way to reconcile refunds automatically.
Why a replacement can be missing
- The plan has no later window scheduled at all.
- The only later windows are already inside the plan's sales cutoff, so they are closed to sales and cannot take new holders; a later date can be visible on the calendar and still not qualify.
- The customer already holds a pass for every remaining window.
- The plan's repeating schedule has passed its recurrence end date, so no later window qualifies even if the calendar still shows dates.
Caveats
- The subscription also emits
subscription.expired, andmember.churnedwhen it was their last active subscription. De-duplicate if you consume several. - No
subscription.refundedfollows unless the creator actually issues the refund in their payment provider, at which point the gateway's webhook records it. - Holders who were paused, past due, or had already cancelled their own pass are not included, even though they may also have paid. Reconcile those separately.
amount_paidis what the subscription recorded at purchase; it does not account for any partial refund already issued.
Related events
pass.window_cancelled: the window-level event, fired once.pass.holder_moved: the other outcome, when a replacement existed.subscription.expired: also fires for this subscription.
Ability to subscribe
A token needs this to subscribe an endpoint to the event.
Header Parameters
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
JSONWhat Subscriby posts to your endpointapplication/json
The signed JSON envelope posted to your endpoint.
The envelope every event is delivered in.
Responses
2XXAny success status
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
defaultAny other status
Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.
How is this guide?