A production gate for OpenAI webhooks: signature verification, fast acknowledgement, idempotency, and replay testing
A reliable receiver uses the raw request body for signature verification, acknowledges within seconds, queues durable work, and deduplicates by webhook-id.
Key takeaways
OpenAI webhooks deliver subscribed events as HTTP POST requests to a project-level endpoint. The documentation says the signing secret appears when the endpoint is created and cannot be viewed again, so it must be stored securely for server-side verification. Official SDK helpers can unwrap and verify an event using the raw request body, request headers, and secret. A receiver should return a successful 2xx response within a few seconds and offload non-trivial processing to a background worker. Failed or slow deliveries are retried with exponential backoff for up to 72 hours, while 3xx redirects are treated as failures. Rare duplicate deliveries are possible, so webhook-id should serve as an idempotency key. A release gate should exercise invalid signatures, duplicates, backlog, replay, and recovery before enabling side effects.
Direct answer
OpenAI webhooks deliver subscribed events as HTTP POST requests to a project-level endpoint. The documentation says the signing secret appears when the endpoint is created and cannot be viewed again, so it must be stored securely for server-side verification. Official SDK helpers can unwrap and verify an event using the raw request body, request headers, and secret. A receiver should return a successful 2xx response within a few seconds and offload non-trivial processing to a background worker. Failed or slow deliveries are retried with exponential backoff for up to 72 hours, while 3xx redirects are treated as failures. Rare duplicate deliveries are possible, so webhook-id should serve as an idempotency key. A release gate should exercise invalid signatures, duplicates, backlog, replay, and recovery before enabling side effects.
Verified facts
Webhook endpoints are configured per project and subscribe to one or more event types; creation returns a signing secret that cannot be viewed again.
OpenAI recommends SDK unwrap helpers to verify the event with the raw request body, request headers, and a server-side secret environment variable.
The endpoint should return 2xx within seconds; failures retry with exponential backoff for up to 72 hours, 3xx redirects are not followed, and webhook-id can deduplicate rare duplicate events.
What changed
- Subscribed events can bring asynchronous results into application workflows
- Verification over the raw request body becomes a mandatory pre-processing boundary
- Fast acknowledgement must be separated from non-trivial business processing
- Retries and duplicates require an idempotent state machine with replay evidence
Impact for AI users
Webhooks replace polling with event-driven delivery while introducing a public endpoint, duplicate delivery, and asynchronous failure. Reliability means that receiving the same event repeatedly still produces one side effect, queued work recovers after a backlog, and redacted logs can reconstruct each state transition. A valid signature establishes origin and integrity; it does not replace an event-type allowlist, object-level authorization, business validation, or idempotency in downstream systems.
Operating checklist
- Use the raw request body for SDK verification, reject missing, stale, or invalid signatures, and keep the signing secret out of logs.
- After verification and minimal field checks, durably record the event with a unique webhook-id constraint, then return 2xx within seconds.
- Process only allowed event types in a background worker, retaining a business idempotency key and state-transition record for every external write.
- Before launch, replay valid, tampered, duplicate, out-of-order, and delayed fixtures, then exercise backlog recovery within the 72-hour retry window.
AI frontier news and analysis, AI software and model tools, AI skill tutorials and validation methods, and AI account and permission guidance
FAQ
Can a verified event trigger a payment or publication immediately?
Signature verification alone is insufficient. Validate the event type, object ownership, business state, authorization, and downstream idempotency first.
Why must the endpoint return 2xx quickly?
OpenAI says slow or unsuccessful responses trigger retries, so non-trivial work should move to a background worker to avoid amplifying duplicates.
Which value should deduplicate repeated deliveries?
OpenAI recommends webhook-id for deduplication. A separate business idempotency key for downstream side effects is this article's engineering recommendation.
Summary
The minimum reliable webhook unit is raw-body verification, durable enqueueing, fast 2xx acknowledgement, idempotent consumption, and auditable replay. Omitting any link leaves side effects uncertain during retries or failures.
This AI-assisted article is checked by ENHE AI automation for official sources, bilingual fields, media rights, page safety, and historical duplication before publication.
What this means for everyday users
Webhooks replace polling with event-driven delivery while introducing a public endpoint, duplicate delivery, and asynchronous failure. Reliability means that receiving the same event repeatedly still produces one side effect, queued work recovers after a backlog, and redacted logs can reconstruct each state transition. A valid signature establishes origin and integrity; it does not replace an event-type allowlist, object-level authorization, business validation, or idempotency in downstream systems.
Tools you may use
Related tutorials
Related Tools And Tutorials
Use the following ENHE AI sections to continue from the news signal into tool selection, account-service guidance, or practical learning.
Related reading
AWS shows how AgentCore can deliver the same MCP tools and interactive widgets across compatible AI hosts
AWS published a technical walkthrough for running MCP Apps on Amazon Bedrock AgentCore on September 11. In the reference architecture, an AI host discovers MCP tools and resources, invokes a tool through WAF and AgentCore Gateway, and receives structured content from business logic implemented with Lambda and DynamoDB. When a tool points to a resource URI, the host reads self-contained widget HTML and renders it in a sandboxed iframe with the structured result injected through the MCP Apps lifecycle. AWS presents MCP Apps as a host-agnostic standard, so one server can provide the same tools and widgets to compatible AI hosts. The production guidance still requires strict argument validation, trust-boundary controls, caller restrictions, monitoring, and cost review.
Mistral and Cloudera target sovereign enterprise AI with customer-controlled training, inference, and operations
Mistral and Cloudera announced a sovereign enterprise AI partnership on September 10. The companies plan to integrate Mistral models with Cloudera's hybrid data platform across public cloud, private cloud, on-premises, and fully air-gapped environments. Mistral says enterprises will be able to train customized models on proprietary data inside controlled environments while retaining ownership of their data and resulting intelligence. The announcement addresses 30 exabytes of customer-managed data on Cloudera's platform and describes customer control over data, open weights, training, inference, infrastructure, jurisdiction, governance, observability, and the learning loop. It does not identify specific model versions, delivery dates, pricing, certifications, or measured customer outcomes, so buyers still need to translate the sovereignty language into testable contractual and technical controls.
Cohere North Small Translate is a 25B-active open-weight MoE built for translation across 50+ languages
Cohere released North Small Translate on September 10, an open-weight mixture-of-experts model dedicated to machine translation across more than 50 languages. The model has 218 billion total parameters and 25 billion active parameters, with 16K input and 16K output context. Cohere lists one B200 or two H100 GPUs at W4A4 as minimum configurations. In vendor-run evaluations using GPT-5.6-Sol as a judge, the standard model scored 83.60 across WMT26 languages and an agentic variant scored 84.36. Cohere also reports up to 1.4 times the output throughput of Gemma 4 31B under identical hardware and concurrency. The model card says the non-commercial CC BY-NC 4.0 license carries an acceptable-use addendum and requires Cohere Labs AUP compliance; commercial production requires a separate commercial license.
DeepSeek V4.1-Flash uses asymmetric MoE activation and a smaller KV cache to target lower inference cost
DeepSeek introduced V4.1-Flash on September 10 as a 552-billion-parameter mixture-of-experts model with native visual understanding. Its new Causal Encoder–Decoder architecture activates 8 billion parameters while processing input and 16 billion while generating output. DeepSeek says the model needs one quarter of the HBM and one eighth of the SSD storage for KV cache compared with the previous generation. V4.1-Flash is available through the DeepSeek API as deepseek-flash, while retired V4 Flash aliases temporarily route to it for compatibility. At this batch's 06:00 Beijing run, the V4-Pro cutover was still in the future: DeepSeek scheduled all deepseek-v4-pro requests to route to V4.1-Flash from 04:00 UTC, or 12:00 Beijing time, on September 14 until V4.1-Pro launches.
IBM and NASA align data from four missions and nine instruments in an open lunar foundation model
IBM and NASA released an open-source Lunar Foundation Model and companion dataset on September 10. The machine-learning-ready dataset combines more than 30 spatially aligned layers from nine instruments across four missions, including tens of thousands of images and maps with different modalities and resolutions. IBM says the model can support work on potential ice deposits, volcanic features, and crater mapping. The IBM-NASA paper reports up to a 22 percent reduction in RMSE for high-potential lunar ice areas and nearly 19 percent better performance than SwinV2-B for crater work at roughly 100-meter context scale while using half the training data. These are results reported by the project partners and should support scientific candidate generation, with domain validation retained before drawing conclusions or planning missions.
Inside OpenAI Habitat: scaling online storage past 70M requests per second and migrating from Python to Rust
OpenAI published an engineering account of Habitat on September 11. The company says its online storage platform now handles more than 70 million requests per second, supports products used by over one billion people each week across almost 40 regions, and serves more than 500 petabytes of data. Habitat began as a Python client library for GPTs in 2023, then became a standalone service so deployments, observability, access controls, audit logging, and platform improvements could be managed centrally. In the second quarter of 2026, two engineers used Codex and GPT-5.5 to rewrite the service in Rust. OpenAI reports that the Rust service now handles 95% of production requests and is six times more CPU-efficient and fifteen times more memory-efficient than the Python version. These are internal production measurements, so other teams should adopt the migration discipline rather than assume identical gains.
