Why I dropped the X API for an IFTTT webhook - and what it cost me

Description and use

The author switched from the X API to an IFTTT webhook to avoid OAuth, but discovered that 200 responses only meant acceptance, not publication. They added error extraction from the webhook body, distinguished accepted vs. published states, and verified posts via the public timeline. launchd PATH and sleep handling were also fixed.

Problem

The author’s bot failed to reliably confirm that tweets were posted when using an IFTTT webhook, because the webhook’s 200 response only indicated acceptance, not publication, leading to a false sense of success.

Outcome

The bot now accurately reports posting success, avoids false positives, and handles launchd quirks, resulting in reliable tweet announcements.

Workflow

• Generate announcement text and enqueue with scheduledAt timestamps
• Launchd job runs every 30 minutes, sending queued items via IFTTT webhook
• Extract errors from IFTTT response body to detect failures
• Treat "published" as null (unknown) and log only "accepted"
• Verify actual posts by scraping the public X timeline

Evidence

IFTTT can return an error in the body while the status stays 200

Source

Treat "published" as null (unknown)

Source

Setting PATH explicitly in EnvironmentVariables fixed node: command not found

Source