Stripe thin event (v2) webhook payload example

Stripe · event: v2.core.account.updated (thin event) · content type: application/json; charset=utf-8

This is a representative sample — fake IDs, real structure. To see a payload with your data, point the provider at a capture URL (button below).

Headers

content-type: application/json; charset=utf-8
user-agent: Stripe/1.0 (+https://stripe.com/docs/webhooks)
stripe-signature: t=1788122465,v1=3c1d7dce7be1ebbead91b961dc6fbab7a2b8d49285ec73ee088716a2852f6814

Body

{
  "id": "evt_test_65Rk9rTAqLxCeQHIjK416TgmEI4ASQ3jHxXt8RFwXoeVwO9",
  "object": "v2.core.event",
  "type": "v2.core.account.updated",
  "livemode": false,
  "created": "2026-08-30T20:41:05.128Z",
  "context": null,
  "reason": {
    "type": "request",
    "request": {
      "id": "req_x9y2z15XqG3Futmjg",
      "idempotency_key": "ik_TgmEI3jHxXt8RFw4jS7ve2QcAReDQWBjPAkAEUm"
    }
  },
  "related_object": {
    "id": "acct_1T93Q4Pmpb34Vto6",
    "type": "v2.core.account",
    "url": "/v2/core/accounts/acct_1T93Q4Pmpb34Vto6"
  }
}

Things that bite people

• There is no data.object. A thin event is a pointer: related_object.id + type, nothing else. Handler code written for classic snapshot events (event.data.object.status…) reads undefined — fetch the latest object from the API (the related_object.url path, with a key that has Read access to that resource) or fetch the complete event from /v2/core/events. In Stripe's SDKs that's parseEventNotification() + fetchRelatedObject() / fetchEvent() — not constructEvent().
• created is an RFC 3339 string with milliseconds ("2026-08-30T20:41:05.128Z") — classic v1 events use a unix integer. Anything that does new Date(event.created * 1000) breaks quietly.
• The signature is unchanged: same Stripe-Signature header, hex HMAC-SHA256 over t + "." + raw body, same whsec_ secret used verbatim. This example's signature actually verifies — paste the body, the header, and the secret whsec_HookdenThinEventDemoSecret2026 into the signature debugger (pick Stripe), or set them on a bin for live ✓/✗ badges. Verification failing on real events? See the exact causes, ordered.
• Thin events are unversioned — no api_version field. That's the point: you upgrade your API version without touching webhook endpoint config. Some thin types keep a v1. prefix (v1.billing.meter.error_report_triggered) — the prefix names the API surface that owns the resource, not a different signature scheme.
• Local dev: plain stripe listen --forward-to … forwards snapshot events only. Thin events need stripe listen --thin-events '*' --forward-thin-to localhost:4242/webhook.
• Delivery behavior (per Stripe's event-destination docs, 2026-08): live mode retries with exponential backoff for up to 3 days; sandboxes retry only 3 times over a few hours. Manual resend works for 15 days from the Dashboard, 30 days via CLI — and does not cancel pending automatic retries. Ordering isn't guaranteed; dedupe on the event id. The Dashboard "send test ping" arrives as v2.core.event_destination.ping.

Send it yourself

Reproduce this delivery against any endpoint (your handler, a bin, staging):

$ curl -X POST https://your-endpoint.example/hook \
  -H 'content-type: application/json; charset=utf-8' \
  -H 'user-agent: Stripe/1.0 (+https://stripe.com/docs/webhooks)' \
  -H 'stripe-signature: t=1788122465,v1=3c1d7dce7be1ebbead91b961dc6fbab7a2b8d49285ec73ee088716a2852f6814' \
 -d '{
  "id": "evt_test_65Rk9rTAqLxCeQHIjK416TgmEI4ASQ3jHxXt8RFwXoeVwO9",
  "object": "v2.core.event",
  "type": "v2.core.account.updated",
  "livemode": false,
  "created": "2026-08-30T20:41:05.128Z",
  "context": null,
  "reason": {
    "type": "request",
    "request": {
      "id": "req_x9y2z15XqG3Futmjg",
      "idempotency_key": "ik_TgmEI3jHxXt8RFw4jS7ve2QcAReDQWBjPAkAEUm"
    }
  },
  "related_object": {
    "id": "acct_1T93Q4Pmpb34Vto6",
    "type": "v2.core.account",
    "url": "/v2/core/accounts/acct_1T93Q4Pmpb34Vto6"
  }
}'

← All payload examples · Related guide · Signature debugger · Docs