Requests

A request represent an HTTP request that Hookdeck receives for a source.

When Hookdeck receives a request for a source, it evaluates for each associated connection whether an event should be created and delivered. Events that do not pass the connection's rules—for example, those filtered out by a filter, identified as duplicates by deduplication, or dropped because the connection is disabled—are recorded as ignored events instead. They do not generate delivery attempts.

When a request produces no events (only ignored events across all connections), it is counted as a discarded request. Discarded requests may be billed depending on your plan. See the pricing page for details.

Rejected requests

A request is marked as rejected if a condition for creating events is not met – for example, if the source is disabled.

Rejection causes

Ignored events

An ignored event is recorded whenever an event is not created for a given connection. Common causes include failing a filter rule, being identified as a duplicate by deduplication, the connection being disabled, or transformation failure. When every connection produces only ignored events for a request, that request is a discarded request.

Ignored event causes

Discarded requests

A request is a discarded request when it produces no events—that is, every associated connection records an ignored event (filtered, deduplicated, disabled, transformation failed, or CLI disconnected). Discarded requests are counted separately from events for billing. Your plan includes a monthly allowance of discarded requests; beyond that, additional discarded requests may be billed. See pricing for details.

Retrying a request

Rejected requests can be retried. Hookdeck re-runs the processing logic on the same request — the request keeps its ID — and creates the associated events.

Retrying a rejected request re-resolves the source's connections as they are at retry time, and re-runs verification. A request rejected with VERIFICATION_FAILED therefore stays rejected unless the source's verification configuration has since been corrected.

Additionally, specific ignored events can be retried individually. Retrying ignored events is narrower than retrying a rejected request: it only re-runs the connections that recorded an ignored event for that request, so it cannot route the request to a connection that did not exist at the time. To reprocess a request against a different set of connections — or onto another source entirely — replay it instead.

Requests eligible for retries

A request is eligible for retry if it was rejected, or if it produced ignored events.

Requests rejected for the following reasons are accepted by the retry endpoint but are not reprocessed, because the condition is permanent:

• UNSUPPORTED_CONTENT_TYPE
• UNPARSABLE_JSON
• PAYLOAD_TOO_LARGE

Request bulk retries

Rejected requests can be bulk retried from the requests page. The bulk retry dropdown will automatically exclude requests that are not eligible for retry. Bulk retries are done asynchronously and may take some time to complete, a progress bar will be displayed once the retry is submitted.

Bulk retry dispatches delivery attempts asynchronously. The dispatch rate is throttled by your per-destination project throughput ceiling. Increasing your project throughput quota also increases bulk retry dispatch speed.

Replay a request

Replaying a request re-ingests the original request through the full pipeline as a brand-new request, creating one new event per target connection. The original request and its events are left unchanged.

Replay is available on any request. Unlike retry — which requires a request that was rejected or that produced ignored events — replay performs no eligibility check at all, so an accepted request with no ignored events can be replayed too.

One case is accepted by the API but not worth replaying: a request rejected with PAYLOAD_TOO_LARGE never had its body stored, so replaying it re-ingests the request without its original payload.

Replay and retry compared

Retry and replay operate on different entities, which is what makes them useful in different situations:

In short: a retry re-runs an existing entity, while a replay creates a new one.

The difference is not old-versus-new connections — retrying a rejected request also re-resolves its source's current connections. The differences that matter are:

• Eligibility: retry requires a rejected request or one with ignored events; replay has no such requirement.
• Targeting: a retry is confined to the request's own source; a replay can target any connections in the project, on any source.
• Verification: a retry re-runs source verification and can stay rejected; a replay carries the original request's verified verdict forward and does not re-verify.
• Entities: a retry mutates the existing request; a replay leaves it untouched and creates new entities.

What a replay re-evaluates

A replay runs against your current configuration, not the configuration in place when the original request arrived:

• Filters, transformations, and deduplication are re-evaluated. A replayed request can therefore produce ignored events, or no events at all, exactly as a newly-arrived request can.
• Verification is not re-run. The replay carries the original request's verified verdict forward, so a replay never fails verification.
• The replay re-ingests the original request in full — headers, path, and query string as well as the body.
• If the target source has no active connections, the replay still creates a new request, rejected with the cause NO_CONNECTION.

Deduplication applies to replays. A connection with a deduplication rule hashes the request's headers, body, query, and path. A replay reproduces all four exactly, so replaying a request within that connection's deduplication window is recorded as an ignored event with the cause DUPLICATE — the replay dedupes against the original. Replay outside the window, or on a connection without a deduplication rule, to avoid this.

Each replay creates a new request and new events, which count toward your usage in the same way as newly-received traffic. A replay that produces no events — including a NO_CONNECTION replay — counts as a discarded request. See the pricing page for details.

A request can only be replayed while its payload is still within your project's retention window. Replaying a request whose payload has been archived returns HTTP 409 with the code DATA_ARCHIVED.

Choosing where a replay is routed

By default, a replay targets every active connection on the original request's source. You can override this:

• Specific connections: replay onto a chosen set of connections.
• A different source: replay onto another source, either across all of its active connections or a specific subset.

When the target connections span multiple sources, the replay fans out into one new request per target source.

Replay a single request

curl -X POST "https://api.hookdeck.com/2025-07-01/requests/req_123456789/replay" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

curl -X POST "https://api.hookdeck.com/2025-07-01/requests/req_123456789/replay" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "source_id": "src_123456789",
    "webhook_ids": ["web_123456789"]
  }'

You can also replay a request from the Events page by replaying an event — see replay an event.

Bulk replay requests

Bulk replay re-runs the pipeline for many historical requests at once, which is the usual way to backfill a new connection or reprocess a time window after fixing a transformation.

A bulk replay works through the matched requests in batches, running each one through the same replay operation as a single replay. Two consequences are worth knowing:

• When you target a source, that source's active connections are resolved separately for every request in the run, so connections added or removed while the run is in progress are honored. When you instead target an explicit set of connections, that set is fixed when the operation is created.
• A bulk replay only covers requests created before the operation started, so it can never pick up its own output.

Like bulk retry, bulk replay dispatches asynchronously. Replayed events are delivered through the same pipeline as any other event, so the dispatch rate is throttled by your per-destination project throughput ceiling.

curl -X POST "https://api.hookdeck.com/2025-07-01/bulk/requests/replay" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "source_id": "src_123456789",
      "target": {
        "source_id": "src_123456789"
      }
    }
  }'

View requests

Hookdeck allows you to browse a historical record of all requests within your retention period, or to filter requests by property. This log is useful for debugging and troubleshooting requests, as well as the events they generate.

Browse all requests

{
  "pagination": {
    "order_by": "ingested_at",
    "dir": "desc",
    "limit": 100
  },
  "count": 1,
  "models": [
    {
      "id": "req_fpSzYE7G0Op42UkKvFOB",
      "team_id": "tm_lbhzBKgFOUnB",
      "verified": false,
      "rejection_cause": null,
      "original_event_data_id": "edt_zjQsVjdTqSMI0cNIPPXE",
      "service_tier": "level1",
      "ingested_at": "2026-01-14T13:36:06.368000Z",
      "source_id": "src_qa5626p6y5o79b",
      "updated_at": "2026-01-14T13:36:06.415515Z",
      "created_at": "2026-01-14T13:36:06.415515Z",
      "events_count": 1,
      "ignored_count": 0,
      "cli_events_count": 0
    }
  ]
}

curl "https://api.hookdeck.com/2025-07-01/requests" \
  -H "Authorization: Bearer YOUR_API_KEY"

Browse filtered requests

Beneath the Requests link, you can find any custom request views, including Hookdeck's default views: Accepted and Rejected.

Filter requests

If your desired filters are not already saved as a filtered view, you can still use the Requests page to find the requests you're looking for.

{
  "pagination": {
    "order_by": "ingested_at",
    "dir": "desc",
    "limit": 100
  },
  "count": 1,
  "models": [
    {
      "id": "req_fpSzYE7G0Op42UkKvFOB",
      "team_id": "tm_lbhzBKgFOUnB",
      "verified": false,
      "rejection_cause": null,
      "original_event_data_id": "edt_zjQsVjdTqSMI0cNIPPXE",
      "service_tier": "level1",
      "ingested_at": "2026-01-14T13:36:06.368000Z",
      "source_id": "src_qa5626p6y5o79b",
      "updated_at": "2026-01-14T13:36:06.415515Z",
      "created_at": "2026-01-14T13:36:06.415515Z",
      "events_count": 1,
      "ignored_count": 0,
      "cli_events_count": 0
    }
  ]
}

curl "https://api.hookdeck.com/2025-07-01/requests?status=rejected&source_id=src_123456789" \
  -H "Authorization: Bearer YOUR_API_KEY"

Filterable properties

The rejection cause and status filters can conflict; in the case where the status is Accepted and a Rejection Cause is set, the status takes precedence.

Inspect a request

Inspecting a request reveals the associated request data, which can be used to understand the flow of events through your system and to troubleshoot issues.

{
  "id": "req_fpSzYE7G0Op42UkKvFOB",
  "team_id": "tm_lbhzBKgFOUnB",
  "verified": false,
  "rejection_cause": null,
  "service_tier": "level1",
  "ingested_at": "2026-01-14T13:36:06.368Z",
  "source_id": "src_qa5626p6y5o79b",
  "original_event_data_id": "edt_zjQsVjdTqSMI0cNIPPXE",
  "ignored_count": 0,
  "events_count": 1,
  "cli_events_count": 0,
  "created_at": "2026-01-14T13:36:06.415515Z",
  "updated_at": "2026-01-14T13:36:06.415515Z",
  "data": {
    "body": {
      "headers": {
        "content-type": "application/json"
      },
      "body": {
        "type": "order.created",
        "customer": {
          "id": "cust_123",
          "email": "customer@example.com"
        },
        "total": 99.99,
        "timestamp": "2026-01-14T13:36:06.365Z"
      }
    },
    "headers": {
      "content-length": "192",
      "content-type": "application/json",
      "user-agent": "axios/1.11.0",
      "x-hookdeck-original-ip": "::1"
    },
    "parsed_query": {},
    "path": "",
    "query": "",
    "is_large_payload": false
  }
}

curl "https://api.hookdeck.com/2025-07-01/requests/req_123456789" \
  -H "Authorization: Bearer YOUR_API_KEY"

For each request, the initial request's headers, path, body, and query are provided either as plain text or JSON. Additionally, a list of events and ignored events resulting from that request will be displayed below the request.

Request and event data

A request's associated events (including ignored events) store data. You can see this data in the right-hand sidebar when you select a request and an event. You can use this data to filter Requests, filter Events in the Events dashboard section, and track and resolve issues.

The displayed events depend on the current project view. Only CLI events will display in the CLI view and vice versa.

Request properties

Event properties

Each event contains properties that can help you track and resolve issues.

Ignored event properties

Custom columns

Custom columns let you display specific payload fields directly in your request list. Add columns for any field in your request data to see the information that matters most at a glance.

Add custom columns

There are two ways to add custom columns:

• From suggested columns: Click on any field in the suggested columns bar above the request list to add it as a column.
• From the request sidebar: Select a request to open the sidebar, then click Add field to table after clicking to any field to add it as a column.

Reorder columns

Drag and drop column headers to reorder them. Your column order is preserved when you save a custom view.

Remove columns

To remove a custom column, click the column header and select Remove column.

Custom columns are saved as part of custom request views, allowing you to quickly access specific information.

Custom request views

Using custom request views allows you to preserve a filtered view of your requests for future access.

Create a custom view

1. Open the Requests page.
2. Make sure Recent Filters is expanded.
3. When the desired filters are set, the results will automatically update.
4. Once satisfied with your filters, click Save View.
5. Name your view and click Save.

Once saved, custom views are accessible in your dashboard's sidebar.

Update filters on a custom view

1. Select the custom view in your dashboard's sidebar.
2. Make sure Recent Filters is expanded.
3. When the desired filters are set, the results will automatically update.
4. Once satisfied with your filters, click Save View.

Rename a custom view

1. Select the custom view in your dashboard's sidebar.
2. Open the dropdown next to the custom view name at the top of the page, and select Rename.
3. Give your custom view a new name and click Update.