Endpoints
The environment’s Webhooks page lists its endpoints with their URL, whether the signing secret is set, the last 24 hours of activity, and the last delivery. Open an endpoint for its tabs:
The endpoint’s details show its URL, source, verification scheme and signing secret actions. See Connect a provider.
Disable an endpoint
Disable an endpoint to stop accepting its deliveries without removing it from your code. Its status becomesinactive and its URL responds with 404, so the provider records failed deliveries and retries them on its own schedule:
POST /api/v1/webhooks/endpoints/{endpointId}/enable. An endpoint that is no longer in the environment’s current deployment is also inactive.
Delivery status
Delivery status tracks routing. Each run it started has its own status and retry history.
Where a delivery went
Open a delivery to see its payload and headers, and a row per subscriber with its result (SUCCEEDED, FILTERED with the reason, or FAILED with the error) and a link to the run it started. Waiting runs are summarized in one row: how many waiters matched, how many were resumed, and how many failed to resume.
A subscriber that fails transiently is retried on its own; subscribers that already succeeded are not run again.
Replay
Replaying a delivery routes its event again as a new delivery. Filters are checked again, so the replay reaches the subscribers that would take the event now:?targetId= to send it to one subscriber regardless of its filter. targetId is the subscriber id: a webhook() task’s id, or agentId:eventId for an agent’s chat.event or channel. A replay never resumes waiting runs.
From an agent or the API
The MCP server haslist_webhook_deliveries (filter by endpoint, status and time), get_webhook_delivery (each subscriber’s result, the waiter summary, the event and headers) and replay_webhook_delivery. The same data is on the REST API:
Deduplication
Trigger.dev uses the endpoint and idempotency key to deduplicate incoming events. Delivery records and task runs have separate deduplication windows:
A retry after the delivery window expires can create another delivery record. If the task-run idempotency window is still active, routing returns the existing run instead of starting another one.
When the source maps a provider event ID, that ID becomes the key. For example, Stripe uses the event body’s
id, and GitHub uses the X-GitHub-Delivery header.
If the source doesn’t map an event ID, the key is derived from the raw body, timestamp, and signature. A retry with a different timestamp or signature can therefore produce a different key. For a custom source, set idempotencyField to a stable event identifier when the provider supplies one.
Verification and recording
Requests must pass the source’s verification checks before they are recorded. Timestamp checks apply when configured by the source. A verification failure returns the source’s rejected HTTP status (400 by default) and creates no delivery or run.
Provider handshakes receive their configured response without creating a delivery. Other verified events are checked for duplicates, recorded, and routed. Filtered and unmatched deliveries stay visible, so you can see what arrived and why nothing ran.