Answer: Postifys may accept work before platforms finish processing. Media queue jobs return 202; publish lanes serialize work per network; YouTube/Meta/TikTok can still process after acceptance.
Practical model
- Prepare media (media requirements).
- Enqueue publish to a platform endpoint.
- Poll/history for completion or failure.
- For TikTok, complete the creator inbox step.
What this means in a real publishing workflow
An HTTP 202 response means Postifys accepted the submission; it does not mean the social network has published it. The worker still has to download or proxy media, refresh the destination token, upload the asset, and wait for the provider response.
Recommended implementation
- Store the Postifys history ID returned with the 202 response.
- Treat queued and processing as non-terminal states.
- Poll post history with reasonable backoff instead of resubmitting the same content.
- Branch only on published or failed, and show the recorded platform error to an operator.
How to verify the fix
A reliable n8n flow saves the history ID beside the source row, marks the row submitted once accepted, and uses a separate status check for the final outcome. This prevents a slow upload from creating duplicates.
Operational check: Test with one item, confirm the final destination and Postifys history state, and only then enable the recurring workflow. Keep the returned Postifys ID beside the source row so every result remains traceable.
Related Postifys resources
API documentation · Error reference · n8n automation guide · Safe retry guide · Compatibility matrix