Skip to main content
GET
Twitter webhook deliveries & retry history
Free - does not consume credits

Path parameters

string
required
The webhook ID to retrieve deliveries for.

Headers

string
required
Your API key.

Operational handoff

Use this endpoint when your queue, CRM, warehouse, or alerting system needs to reconcile webhook delivery health. It returns the 100 most recent delivery records for one webhook, newest first. Map each delivery into a small incident row before sending it downstream. Keep id, streamEventId, status, attempts, receiver status, timestamps, and the chosen action; avoid dumping the full response into logs. This endpoint returns delivery attempt metadata only. It does not return the webhook URL, event type filter, signing secret, raw payload body, raw signature, or full request headers. Do not depend on a nextRetryAt field. The response does not expose one; route incidents from status, attempts, lastStatusCode, lastError, createdAt, and deliveredAt. Store these fields for support and retry triage:

Delivery ID

Store id for delivery-level idempotency and support lookup.

Event join

Store streamEventId to join back to the stored monitor event with GET /events/{id}.

Status route

Use status to route pending, failed, and exhausted deliveries to the right queue.

Attempt count

Use attempts to decide whether a failed delivery is early, repeated, or at the retry cap.

Receiver result

Use lastStatusCode to separate receiver errors such as 500 from unreachable endpoints with status 0.

Failure reason

Show lastError as the most recent failure reason for the operator.

Timing

Compare createdAt and deliveredAt to measure delivery latency and recovery time.

Incident response handoff

Use one compact handoff row when a delivery needs receiver-owner action. Route delivered rows out of the incident path, track pending, warn on repeated failed, and page on exhausted.

Repeated failure

Warn after repeated failed rows. Include attempts, lastStatusCode, and lastError so the receiver owner can separate code errors from reachability failures.

Terminal delivery

Page when status is exhausted. This means retryable failures reached the 10-attempt cap, or the receiver returned 410 Gone.

Event join

Store streamEventId and link GET /api/v1/events/{id} so support can inspect the monitor event that triggered the delivery.

Receiver proof

After fixing the endpoint, send POST /webhooks/{id}/test and attach the signed test result to the incident before waiting for the next event.
Failures retry up to 10 attempts with exponential backoff, starting at 1 second and capped at 60 seconds. A 410 Gone response marks the delivery exhausted immediately. Other non-2xx responses and network failures stay failed until they are delivered or exhaust all attempts. For incident response, page on exhausted, warn on repeated failed, and ignore delivered. Fix the receiving endpoint, then use POST /webhooks/{id}/test to confirm it accepts signed requests before waiting for the next production event.

Receiver backfill handoff

This endpoint returns the latest 100 delivery rows for one webhook. Use those rows to identify receiver failures, then use stored event pages to rebuild your own downstream queue after the receiver is fixed.
Store nextCursor after every event page. Continue GET /api/v1/events?limit=100&cursor={nextCursor} until hasMore is false, then compare each event id with delivery streamEventId values before replaying your own downstream work. Add monitorId when replaying one account monitor, or keywordMonitorId when replaying one keyword monitor.

Response

200 OK

array
List of delivery attempts, most recent first. Returns up to 100 deliveries. Delivery object fields.
string
Unique delivery identifier.
string
ID of the stream event that triggered this delivery.
string
Current delivery status: pending, delivered, failed, or exhausted.
number
Total number of delivery attempts made.
number
HTTP status code returned by your endpoint on the most recent attempt. Omitted if no attempt has been made yet.
string
Error message from the most recent failed attempt. Omitted on success.
string
ISO 8601 timestamp of when the delivery was queued.
string
ISO 8601 timestamp of successful delivery. Omitted if not yet delivered.

401 Unauthenticated

Missing or invalid API key. Check the x-api-key header value.

400 Invalid ID

The provided webhook ID is not a valid format.

404 Not found

No webhook exists with this ID, or it belongs to a different account.

429 Rate limited

Too many requests. Wait for the Retry-After header before retrying.

Delivery statuses

pending

Delivery is queued and waiting for the next attempt.

delivered

Your endpoint returned 2xx. Delivery is complete.

failed

The most recent attempt failed because the endpoint returned non-2xx or the network request failed. Xquik retries with exponential backoff.

exhausted

All retry attempts have been used. Xquik will not retry this delivery. Check the receiver endpoint, then use Resume Webhook if the webhook needs attention before new deliveries continue.
Deliveries follow an exponential backoff retry schedule. After each failed attempt, the wait time increases. Once all retries are exhausted, the status transitions to exhausted and no further attempts are made.