Direct answer
The short version
Treat every AI video callback as an untrusted notification, not final proof that a job completed. Verify the provider-specific signature or trusted event path, deduplicate by event and task identifiers, persist the event before doing heavy work, query the provider's result API to reconcile state, and return a fast success response. Keep bounded polling or scheduled reconciliation as a fallback, because a delayed or missing callback must never trigger an automatic duplicate generation.
Is a callback enough to mark a video job complete?
No. A callback should wake the workflow and identify the task that needs reconciliation. The workflow should then compare the incoming event with its stored task record and the provider's current result before changing the buyer-facing state.
Alibaba Cloud documents an EventBridge completion event for Model Studio asynchronous tasks and tells the recipient to call the task-result API once after receiving the notification. Vidu documents callback bodies that match its generation-result response. These are different delivery designs, but neither removes the need to bind the event to the correct account, route and task in your own system.
- Match the event to the stored provider, endpoint, model and task ID
- Confirm the provider result before exposing success or failure downstream
- Keep the original submission record separate from callback delivery records
- Do not create a replacement generation merely because notification delivery is delayed
How should an incoming callback be authenticated?
Use the method documented for the exact provider and route. Vidu documents an HMAC-SHA256 signature built from the HTTP method, request URI, query string, a fixed access-key field, Date and an ordered set of signed headers. Its documentation also includes a nonce to help prevent replay. The canonical string is formatting-sensitive, so verify against captured examples before enabling production traffic.
Do not invent a universal webhook signature. Alibaba's cited Model Studio workflow routes completion events through EventBridge to an HTTP endpoint or RocketMQ, so the trust boundary and controls are different. Record the current event source, target and account configuration, and follow the provider documentation for that path.
- Read the raw request body before any parser changes whitespace or encoding
- Compare signatures without leaking keys or signature material into logs
- Reject stale timestamps, reused nonces or unexpected source configuration when supported
- Bind verification rules to a versioned provider adapter rather than a shared generic rule
How do you prevent replayed or duplicate callbacks?
Assume the same event can arrive more than once. Delivery retries are a reliability feature, not a promise of exactly-once processing. Store a deduplication key built from the provider event identifier when one exists, together with the task ID and a bounded retention window. If the provider supplies a nonce or timestamp, validate it as part of the replay check.
Make task transitions monotonic. A repeated success event should not download the output twice, and an older processing event should not move a completed task backwards. A duplicate should be acknowledged only after the first accepted event is durably recorded or the duplicate is safely recognised.
- Use provider event ID plus task ID as the preferred idempotency key
- Persist the first accepted event before enqueueing reconciliation
- Ignore state regressions and repeat side effects
- Keep deduplication records longer than the documented delivery retry window
What should the callback endpoint do before returning?
Keep the synchronous path short: enforce body and time limits, authenticate the request, validate the minimum schema, persist the event and enqueue reconciliation. Return the documented success response promptly after durable acceptance. Downloading a generated video, transcoding it or copying it to long-term storage belongs in a separate worker.
This boundary makes retry behaviour predictable. It also prevents a slow object transfer or downstream outage from making the provider believe that callback delivery failed.
- Bound request size and processing time
- Persist content-free event metadata before acknowledging
- Queue result reconciliation and output retrieval separately
- Log task and event identifiers, not prompts, media or credentials
What happens when a callback is late or never arrives?
A callback is not the only source of truth. Vidu documents three retries after a failed callback delivery, which is useful but bounded. Alibaba documents a result-query step after EventBridge notification and a 20 QPS limit for the cited asynchronous task-result API. Your fallback must respect the exact route's current limits and retention window.
Use a scheduled reconciliation job for tasks that remain non-terminal beyond the expected interval. Poll with backoff, stop at a documented deadline and surface an operational exception. Never resubmit the billable generation automatically just because a callback was not observed.
- Define an expected callback window for each provider route
- Reconcile overdue tasks with bounded, rate-aware result queries
- Separate notification failure from generation failure
- Require an explicit decision before any replacement generation
What belongs in the callback test matrix?
Test the failure modes that change cost or buyer-visible state, not only the happy path. Run the matrix against a non-production workload with traceable task IDs, then keep the evidence needed to repeat it after a provider, model, endpoint or region change.
Provider documentation is the starting point, but live account behaviour is the release gate. Record observed delivery timing and retry behaviour without claiming that one account's result is a universal provider guarantee.
- Valid callback followed by a successful provider result query
- Invalid signature, stale timestamp and replayed nonce
- Duplicate and out-of-order events
- Temporary endpoint outage followed by a provider retry
- Accepted callback followed by a failed result query
- Delayed or missing callback recovered by scheduled reconciliation
Which decision criteria make callbacks production-ready?
Approve a callback route only when authentication, idempotency, monotonic state handling and recovery have all been tested for the exact provider route. The workflow must complete correctly when the callback is duplicated, delayed or absent, and it must never convert notification uncertainty into an uncontrolled new generation.
The production record should identify the provider account and region, the current event-delivery path, result-query limits, retry observations, logging boundaries and any separate messaging or EventBridge charges. Retest when any of these dependencies changes.
- Provider-specific authentication is implemented and regression-tested
- Duplicate and replayed events cannot repeat side effects
- Task state cannot move backwards
- A bounded reconciliation path works without callback delivery
- Notification failure cannot create a duplicate generation
- Region, account, rate-limit and event-delivery cost assumptions are documented
Frequently asked questions
Questions buyers ask next
Can callbacks replace polling for Chinese AI video APIs?
Not completely. Use callbacks or event notifications as the primary wake-up signal, then reconcile with the provider's result API. Keep bounded polling or scheduled reconciliation for delayed or missing notifications.
Should I trust the callback body as the final job result?
No. Authenticate the request, bind it to the stored task and query the provider's current result when the route supports or requires that pattern. Treat the callback as a notification until reconciliation succeeds.
What should happen when the same callback arrives twice?
Recognise it with a durable idempotency key, acknowledge it after safe persistence and do not repeat downloads, state transitions or other side effects. Duplicate delivery must never create another generation.
Do Chinese AI video providers use the same callback signature?
No. Vidu documents an HMAC-SHA256 callback signature with specific canonicalisation fields, while the cited Alibaba Model Studio path uses EventBridge delivery. Implement and test the current rules for each exact route.
Primary sources
Evidence reviewed
Provider documentation changes. Recheck the live source before making a procurement decision.
- Vidu API: callback signature verificationAccessed 2026-09-29
- Vidu API: reference-to-video callback behaviourAccessed 2026-09-29
- Alibaba Cloud Model Studio: asynchronous task API and EventBridge notificationsAccessed 2026-09-29