When a video request times out, first establish whether the service already accepted it. Retrying with a new operation identity can create more work instead of recovering the missing response. The risk is greater for publication, where an unnecessary second write can become a second public post.
Use the original job ID when you have one. If the response was lost, preserve the exact request and its idempotency key, then follow the operation's documented retry behavior. Do not generate a fresh key simply because the first attempt became uncertain.
This guide explains a recovery design using Prolifik's current API contract. It does not claim that every video service, every endpoint or every client implements the same protections.
Distinguish the two kinds of timeout
In the first case, the service returned a job ID and the observer stopped waiting for the render. That is a readback problem. Retrieve the same job. A second create call is unnecessary.
In the second case, the create request may have arrived, but the response never reached the caller. That is an uncertain write. The local log needs the intended operation and key so the caller can recover without inventing another job.
A fictional incident illustrates the difference. An assistant submits one Text Story for a repair-booking app. The connection drops before it sees the response. The next turn should recover that attempt, not interpret “try again” as permission to create a second version with new copy.
Persist the identity before sending the request
Store a small operation record outside the temporary conversation:
| Field | Purpose |
|---|---|
| Local operation ID | Identifies the intended unit of work |
| Service operation | Distinguishes content creation from publication |
| Idempotency key | Reuses the same identity for an eligible replay |
| Exact request data | Detects accidental changes between attempts |
| Returned job or post ID | Supports read-only recovery once known |
| Last observed result | Distinguishes uncertainty from a known failure |
Do not store an API secret inside this record or print it in an error report. The operation record describes the work; credentials belong in an appropriate secret store or authenticated client configuration.
The content-agent architecture guide covers durable state more broadly. Here, the important detail is that identity exists before the first write, not only after a success message.
Understand what a replay protects
Prolifik's idempotency implementation binds the key to the operation, principal and canonicalized request data. The current reservation window is 24 hours. An already recorded response can be replayed for the same eligible request; it is not a permanent deduplication database for your campaign.
Current content-job creation and content publication require a key. Some operations that act on an existing row accept optional idempotency and have additional state guards. Read the specific endpoint instead of assuming a single rule covers all writes.
Use a fresh identity for a genuinely new intended action. A second video with changed copy is new work. A second attempt to obtain the first video's response is not.
Treat conflicts as information, not obstacles to bypass
An existing key with different request data produces a conflict. Do not solve it by removing the key and resubmitting blindly. Compare the stored request with the new one and decide whether the work changed intentionally.
An in-progress reservation can also produce a conflict with advice to retry shortly. That does not establish that nothing happened. Preserve the original identity and follow the response rather than trying a different key to get around the guard.
If the reservation window has expired, do not assume reusing the old key still provides the original replay protection. Reconcile existing job or publication records first. Long-lived deduplication needs your own durable mapping from intended work to actual service identifiers.
Test the recovery branches without public side effects
Use a controlled test fixture or a non-public, explicitly authorized test workflow. Cover these cases: same key and same payload, same key with changed payload, interrupted response, known job ID after disconnect, and observation timeout during processing.
For a publishing integration, do not test duplicate prevention by posting repeatedly to a real customer's account. Mock the write boundary or use a dedicated test environment with clear authorization. Inspect which branch would submit another write before allowing it to act publicly.
Record the expected number of intended operations. If a simulated response loss changes that count from one to two, the recovery path is creating work rather than recovering it.
Recover a render and a post separately
Once a job ID exists, poll its retrieval operation. Once a publication record exists, inspect that publication record and provider outcome. A rendered video, a scheduled post and a public item remain separate facts.
Do not assume that fixing a render failure should repeat a prior publication request. Confirm the accepted media version, intended destination and timing again if the creative output changes.
The MCP scheduling guide covers the authorized publication handoff. For implementation details, use the Prolifik API idempotency reference. A safe retry preserves one intended operation, its evidence and its scope instead of turning uncertainty into duplicate content.
Implement the documented replay boundary
Match each intended operation to its original request identity and current endpoint-specific idempotency rules.
Read API idempotency rulesFacts checked 2026-10-24. Worked examples are illustrative unless a real source is identified.
- Prolifik API idempotency and endpoint requirements Checked 2026-10-24
- Prolifik MCP creation and publication tools Checked 2026-10-24