What a production posting API must handle
A reliable posting API defines more than a create endpoint. It needs a stable content model, clear destination identifiers, timezone-aware scheduling, media rules, validation errors, authentication scopes, request limits, and an item identifier that can be read after the initial response.
The API also needs to separate submission from delivery. Accepting a scheduled job means the content entered the queue; it does not prove that a third-party destination later returned a live post. Clients should store the Narrareach item identifier and check the final state or consume supported webhook events.
Retries require special care. Narrareach article requests support an idempotency key so a caller can safely retry a timed-out submission without intentionally creating the same article twice. Clients should also back off on rate-limit and transient failures rather than sending an immediate request loop.
- Treat the queue response and final destination result as separate states.
- Store the Narrareach identifier and your own source identifier together.
- Use a stable idempotency key for supported article requests that may be retried.