Answer: Prefer n8n when you need a custom calendar source (Sheets/Airtable/CRM), approval gates, or multi-client logic. If you only need interval + timezone scheduling across connected Postifys accounts, use the built-in Content queue on Create & schedule — no n8n required.
Without n8n: Open /compose → Content queue → create a data table and import CSV → create a job that selects that table and your accounts → set interval hours and timezone → enable auto-post. One job per table (same idea as one n8n workflow per data table).
Architecture
- Content calendar sheet/DB: datetime (with timezone), caption, media URL, destination account ids.
- n8n Schedule trigger polls due rows.
- For each due row, run platform-specific Postifys nodes.
- Write back status + history references.
Tips
- Store Postifys connection ids, not display names.
- Stagger TikTok/YouTube heavier uploads if you hit temporary-media pressure.
- Use approval workflows for brand-sensitive accounts.
- Keep secrets in n8n credentials, never in sheet cells.
Production workflow checklist
| Step | n8n node or action | Why it matters |
|---|---|---|
| 1 | Schedule Trigger | Runs in one documented timezone so posts do not drift between client regions. |
| 2 | Database, Sheet, or CRM lookup | Fetches due content rows with platform, caption, media URL, and stable Postifys connection IDs. |
| 3 | Set / Code node | Builds one payload per destination and adds an idempotency key from the source row ID plus platform. |
| 4 | Split in Batches | Prevents one large media item from flooding every connected account at the same second. |
| 5 | HTTP Request or Postifys node | Sends the publish request and stores the returned Postifys ID beside the original row. |
| 6 | Wait + status check | Checks async processing, final platform state, retry count, and any provider-specific error. |
| 7 | Update source row | Writes published, waiting-user, failed, or retrying status separately for each destination. |
Duplicate protection: If the workflow restarts, it should look for an existing Postifys ID or idempotency key before sending another publish request. This protects live client accounts from accidental duplicate posts.
Starter: scheduled Facebook feed · all templates · Use case: multi-account publishing
What this means in a real publishing workflow
Multi-account scheduling needs deterministic account mapping and concurrency control. Display names help operators, but stable destination IDs must remain authoritative when multiple clients have similar Page or channel names.
Recommended implementation
- Store the intended platform and destination ID with each content row.
- Evaluate schedules in one documented timezone.
- Claim rows atomically before publishing.
- Stagger heavy media work and maintain separate status fields per destination.
How to verify the fix
Test daylight-saving changes, missed schedules, workflow restarts, and overlapping executions. A resumed job must not reclaim a row already submitted.
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