Retry safely with idempotency
Prevent duplicate remote posts when requests, queues, or provider responses are ambiguous.
Send a unique Idempotency-Key on side-effecting mutations and reuse it only for the exact same logical request. For failed delivery targets, use the retry action so App9 Post can reconcile existing attempts and remote IDs before another provider call.
What this means in practice
Send a unique Idempotency-Key on side-effecting mutations and reuse it only for the exact same logical request. For failed delivery targets, use the retry action so App9 Post can reconcile existing attempts and remote IDs before another provider call.
Use the documented brand and account boundaries consistently across the scheduler, REST API, SDK, MCP tools, SSE consumers, and webhooks. That makes the same social operation explainable to an operator and reproducible by an integration.
Implementation checklist
Generate the key when the logical operation begins, not on every network retry.
Persist the key with the client job until a definitive API response is recorded.
Reuse the key only when method, path, brand, and request body are unchanged.
Use structured retry classifications and provider reset information.
Inspect results after timeouts before creating replacement content.
Example request
This example uses a server-side API key and an explicit brand selection. Replace placeholder values and keep credentials out of browser bundles, client logs, and source control.
curl --request POST \
--url 'https://postapi.app9.co/v1/social-posts/POST_ID/retry' \
--header 'Authorization: Bearer APP9_POST_API_KEY' \
--header 'X-App9-Post-Brand: BRAND_ID' \
--header 'Content-Type: application/json' \
--data '{
"target_ids": [
"target_failed_123"
]
}'Operational details
An idempotency conflict indicates the same key was used with different request content.
Target leases and remote external IDs add duplicate protection beyond the HTTP request layer.
Retries cannot produce more than one delivery charge per target.
Common mistakes to avoid
- Do not generate a fresh key after every client timeout.
- Do not automatically retry non-retryable content-policy or permission failures.
- Do not use one global idempotency key for a batch of distinct posts.