{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigkwyhu52qur542haidthwdsss5yqhpfagvt2zcelovjwhu5gequm",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mnfdzgy5zua2"
  },
  "path": "/t/need-more-info-about-webhooks/1378880#post_3",
  "publishedAt": "2026-06-03T14:23:44.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "@Mr.Bless"
  ],
  "textContent": "Hey @Mr.Bless — the missing delivery log is the part I’d flag too. Until OpenAI ships native logging, Mark’s “log webhook deliveries yourself” workaround is basically the whole job: put a capture proxy in front of your endpoint so every delivery — headers, body, `webhook-id`, timestamp, and your endpoint’s response — gets recorded, then forwarded on to your real handler.\n\nThat’s what I built FlurryPORT for (disclosure: it’s mine). Point OpenAI’s webhook at the FlurryPORT capture URL and set the forward target to your actual endpoint. You get a full log of every attempt — including the 72h retries and any duplicate `webhook-id`s, so you can see exactly what to dedupe on — and you can **replay** any captured delivery against dev or prod, which partly covers the env-isolation gap since OpenAI’s scoping is project-level only. There’s a free, no-account version at flurryport.dev if you want to try it against a throwaway endpoint first.\n\nIt won’t add the pause/resume or per-API-key config you’re asking OpenAI for — those have to come from their side — but it makes deliveries visible and replayable today.",
  "title": "Need more info about webhooks"
}