Scheduling

Publish modes

When creating a post, FeedHorizon supports four publish modes:

• now - publish immediately
• schedule - publish at a future date/time
• queue - reserve for queue-based publishing
• draft - save without publishing

Schedule a post

curl -X POST https://app.feedhorizon.dev/api/v1/posts \
  -H "Authorization: Bearer fh_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Launching tomorrow at noon",
    "platforms": ["linkedin"],
    "profileId": "YOUR_PROFILE_ID",
    "scheduledFor": "2026-03-10T12:00:00",
    "timezone": "America/New_York"
  }'

Timezone behavior

• scheduledFor is interpreted in the provided timezone
• FeedHorizon converts the value to UTC before storing and processing
• Always pass an IANA timezone (for example Europe/Berlin, America/New_York)
• If you omit timezone in dashboard flows, browser timezone is typically used

Scheduling pipeline

graph TD
    A[Post created with schedule mode] --> B[Status set to SCHEDULED]
    B --> C[Cron checks due posts every minute]
    C --> D[Due post marked QUEUED]
    D --> E[System publish starts]
    E --> F[Status PUBLISHING]
    F --> G[Platform clients publish per target platform]
    G --> H{Any successful publish}
    H -->|Yes| I[Status PUBLISHED]
    H -->|No| J[Status FAILED]

Status lifecycle

For scheduled posts, the usual lifecycle is:

SCHEDULED -> QUEUED -> PUBLISHING -> PUBLISHED

If all platform attempts fail:

SCHEDULED -> QUEUED -> PUBLISHING -> FAILED

Retry failed posts

If a scheduled post fails, use the retry endpoint:

curl -X POST https://app.feedhorizon.dev/api/v1/posts/POST_ID/retry \
  -H "Authorization: Bearer fh_YOUR_API_KEY"

Best practices

• Prefer explicit timezone for all scheduled requests
• Validate content and media constraints per platform before scheduling
• Subscribe to Webhooks for post.published and post.failed
• Use Rate Limits guidance when scheduling in bulk