Hi OpenAI team,
The current doc around webhooks is not sufficient. It doesn’t tell about if webhook request failed what is the retry mechanism. I also noticed that there is no way to view the webhook request log on OpenAI.
For the background response api using the shell tool it is important to know these details as the container would be destroyed if the resource is not accessed on time (like after 20 mins of container inactivitiy).
Also it would have been great if there is an option to configure webhook endpoint where one can configure/select API keys for which webhook is valid for configured endpoint.
I have multiple api keys for different envs with the same project but with current setup it seems the api will be called even for the envs it is not desired for.
Also IMO it lacks one of the essential feature of the webhooks configuration; pause and resume.
It would be great if you could point where could I find the documentation around it.
Thanks!
Good callout @Mr.Bless, a few of these are confusing right now.
Retry behavior is documented here: failed webhooks (non 2xx or timeout) get retried with backoff for up to 72 hours, and duplicates can happen so you’ll want to dedupe with webhook-id.
What’s currently not supported:
- No webhook delivery logs in OpenAI
- No per API key or env scoping, it’s project-level
- No pause or resume control
Workarounds folks are using:
Separate projects for dev and prod if you need strict isolation
Or tag requests with metadata like env=prod and filter on your side
Log webhook deliveries yourself using webhook-id
- For shell/background jobs, don’t rely only on webhooks, also poll
responses.retrieve
We’ll also pass the logging gap to the team as feedback since that one comes up a lot.
-Mark G.
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.
That’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-ids, 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.
It 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.