Answer: Use Post History as the source of truth for multi-platform jobs. Meta inbound webhooks exist for specific cases; do not assume universal completion webhooks for every network yet.
What works today
- Post History / dashboard - primary status across lanes.
- API health -
/healthfor service readiness. - Meta inbound webhooks - configured for supported Meta events; not a full substitute for every platform’s final “live” state.
- n8n polling - Wait + HTTP Request / history lookup when you need workflow branching.
Status detail: TikTok Direct Post remains asynchronous after acceptance, so poll until publish completes or fails. Draft Upload acceptance means the creator still must finish publishing in TikTok.
n8n pattern
- Publish via Postifys node.
- Store returned identifiers.
- Wait / poll history until terminal success/fail or timeout.
- Branch notifications on outcome.
Related: webhooks overview · webhook docs · async publishing
What this means in a real publishing workflow
A durable status system starts with the Postifys history ID returned at submission. Webhooks can reduce polling where supported, but the history record remains the reconciliation source when callbacks are delayed, duplicated, or unavailable.
Recommended implementation
- Persist every history ID and destination.
- Authenticate and deduplicate incoming webhook events.
- Poll non-terminal records with backoff when no final callback exists.
- Alert on failed states with the recorded provider message.
How to verify the fix
Design webhook handlers to be idempotent and keep a periodic reconciliation job. Never assume callback ordering or exactly-once delivery.
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