Webhook Processing Reconciliation

A webhook dashboard can say “delivered” while the application worker never records successful processing. Compare your delivery-attempt metadata with a separate application processing ledger to find that gap after a deploy or in a daily integration audit.

This Actor produces a review queue with exact event scopes, delivery IDs, processing IDs, timestamps, coverage explanations and JSON Pointers to your supplied rows. It accepts metadata exports; it does not require provider credentials, customer payloads or an external API subscription.

What it checks

• Acknowledged events without successful application processing beyond your chosen delay, when complete comparable exports support the finding.
• Pending processing older than your policy, using the supplied application receipt time.
• Distinct successful processing records for one logical event and consumer, as possible repeated processing evidence.
• Processing records without delivery evidence, with a confirmed orphan finding only when complete coverage and an in-window receivedAt establish the comparison.
• Conflicting record IDs, repeated export rows, missing coverage, stale windows, out-of-window rows and future or impossible times.

An HTTP 2xx acknowledges delivery. It is not proof that your worker processed the event. Two transport attempts are legitimate retry evidence. Two successful processing IDs suggest possible repeated application processing; they do not prove that an invoice, order or other real side effect happened twice. Failed application and transport records remain visible alongside later supplied success, without claiming an event ordering from provider creation timestamps.

Input and identity

Supply one JSON object containing all five required fields:

{
  "asOf": "2026-10-01T11:00:00Z",
  "maxProcessingDelayMinutes": 5,
  "coverage": [{
    "scope": {"provider":"example","account":"account-001","subscription":"orders","consumer":"order-worker"},
    "delivery": {"from":"2026-10-01T09:00:00Z","to":"2026-10-01T11:00:00Z","complete":true},
    "processing": {"from":"2026-10-01T09:00:00Z","to":"2026-10-01T11:00:00Z","complete":true}
  }],
  "deliveries": [{
    "attemptId":"delivery-001",
    "scope":{"provider":"example","account":"account-001","subscription":"orders","consumer":"order-worker"},
    "eventKey":"event-001",
    "timestamp":"2026-10-01T10:00:00Z",
    "outcome":"acknowledged",
    "httpStatus":200
  }],
  "processing": []
}

This example yields an acknowledgment gap aged 60 minutes. The full synthetic fixture in examples/input.json also demonstrates a recovered retry, repeated successes, recent pending work, an orphan, partial coverage and a future record.

The four exact, case-sensitive scope values plus eventKey identify a logical event. Use aliases when identifiers are confidential. Preserve IDs as strings, including leading zeros. attemptId identifies one delivery attempt; recordId identifies one application ledger entry. These IDs must be unique within their entire respective input table. Prefix locally reused IDs with a stable source namespace before exporting. Delivery and processing IDs are separate and may coincide without joining different events.

Deliveries accept acknowledged, failed or pending. Optional httpStatus must be 2xx for acknowledged, non-2xx for failed, and omitted for pending. Processing accepts succeeded, failed or pending. timestamp means the actual recorded state time; optional receivedAt means receipt by your application. A pending state update time cannot replace receipt time. Use real UTC timestamps with seconds and optionally exactly three fractional digits. Unknown fields are rejected, including payload/header/token fields.

Preparing inexpensive exports

Export only these metadata columns from your existing receiver log and worker ledger. Generate a distinct attempt ID for each receipt/response attempt, even when the provider retries the same event. Keep the provider event correlation ID in eventKey. Keep the subscription and consumer explicit: two legitimate subscriptions or workers must remain separate scopes. For Shopify, distinguish delivery identity from event correlation identity. For Stripe, do not substitute a second-resolution event-created timestamp for receipt or processing time. Map provider response status to acknowledgment, never to application success.

For a daily audit, choose one exact asOf and a start time retained by both systems. Read both exports over those same closed intervals, including endpoint timestamps. Retrieve every page and include all matching scopes, attempts and ledger records. Mark complete:true only after confirming retention, filters, pagination and source access. If your exporter uses half-open database queries, adapt its boundary explicitly rather than silently omitting the last instant. A useful receiver/worker SQL export recipe is provided in docs/EXPORT-RECIPE.md.

For current missing-event comparisons, both declared windows must be complete, identical and end at asOf; otherwise the finding stays uncertain. Rows outside a declared window or beyond asOf remain unresolved evidence and are excluded from current state. Processing before receivedAt is unresolved. Nothing absent from every supplied source can be discovered.

Repeated identical IDs with exactly equal normalized field values are counted once. Object-key order is ignored after typed normalization; timestamp spellings and string values are compared exactly. Conflicting versions are all quarantined. Conflict pointers include each affected event's rows plus a differing comparison pair, keeping a large ambiguous export bounded.

Downloads and repeat usage

The dataset contains one complete report item with summary, events, coverage, rows and limitations. Each evidence row has a stable issue ID for unchanged input, scope, event key, related attempt/processing IDs, age when valid, source pointers and a reason. Event states partition into processed, pending, review or uncertain; a supplied success can still be present on an uncertain event. Review and uncertainty counts are reported separately.

Download full JSON from OUTPUT, flat evidence CSV from reconciliation.csv, or a standalone HTML report from report.html. CSV protects spreadsheet formula cells; HTML escapes identifiers and includes no external scripts. Reuse your normalization and delay policy for the next daily export or deployment. Review uncertain evidence before declaring an integration healthy.

Price, limits and recovery

Price: $0.25 per completed report, including platform usage. One new run with the same input is a new billable report. There is no startup fee or per-row event. Maximum input is 2 MB UTF-8 JSON, 10,000 combined metadata rows and 500 coverage declarations. The allowed delay is an integer from 1 to 10,080 minutes. Full JSON must stay below 8 MB and each export below 9 MB; every export is checked before charging. Split dense exports if these output limits are reached.

The primary paid deliverable is the complete dataset item. If convenience export writing is interrupted after delivery, resurrecting the same run verifies the input and saved report, then repairs downloads without another report charge or dataset item. Missing or modified saved data is rejected. An interruption between dataset writing and event charging can charge the intact saved report once on recovery. This does not promise atomic delivery of every download during platform outages.

The Actor compares caller-supplied evidence. It does not validate signatures, receive live webhooks, replay events, retry workers, modify queues or independently verify declared completeness or business side effects.