When a connection dies

The short version

A connected account can stop working without you doing anything: you remove Chirpie's access on the platform, the platform expires the connection, or a Bluesky app password is rotated. When that happens Chirpie switches the account off, cancels everything you had scheduled on it and gives the quota back, marks the account so your code can see it, and emails you (at most once per platform per day, so one dead connection is one message).

Nothing you have already published is affected, and your other connected accounts keep publishing as normal.

How to detect it

Pause on is_active, then read inactive_reason to decide what to do. An account with is_active: false cannot publish, whatever the reason, and a deliberately deactivated one carries no inactive_reason at all, so pausing only when that field is present would keep posting into a dead account.

curl https://chirpie.ai/api/v1/accounts \
  -H "Authorization: Bearer chirpie_sk_your_key"

{
  "data": [
    {
      "id": "550e8400-e29b-41d4-a716-446655440000",
      "platform": "x",
      "username": "yourhandle",
      "is_active": false,
      "inactive_reason": "token_revoked"
    }
  ]
}

Stop rather than retry. An agent that posts on a schedule should check is_active before a run and stop when it is false: no number of retries fixes a credential the platform has stopped accepting, or an account that is simply switched off. inactive_reason then says whether the fix is activateAccount() or a fresh connect.

What happened to your scheduled posts

They were cancelled, not left pending. A post queued against an account that cannot publish would sit there for ever, so Chirpie cancels the whole queue for that account the moment it finds out, refunds both your monthly post quota and your scheduled-post allowance, and records why on each post:

{
  "data": {
    "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "status": "deleted",
    "error_message": "connection_lost",
    "retry_count": 0
  }
}

A thread is cancelled as a unit, so you never end up with half of one queued.

Reconnecting does not bring them back. Reschedule whatever you still want to go out.

The email

Chirpie emails the address on your account, at most once per platform per 24 hours, so one dead credential sends one message rather than one per post, and one revoked grant covering several accounts (a set of Facebook Pages, or a set of LinkedIn Company Pages) sends one message rather than one per Page. It names the platform and how many scheduled posts were cancelled.

Getting back to publishing

1. Open Connected Accounts. The account shows Reconnect.
2. Connect it again. OAuth platforms (X, LinkedIn, Threads, Mastodon, Instagram, Facebook) send you through the platform's consent screen. Bluesky takes a fresh app password; Telegram takes the bot token and chat again.
3. Reschedule anything that was cancelled.

Reconnecting an account you already hold never needs a free slot against your plan's account limit, and the account keeps its account_id, so nothing you have stored has to change.

A post that simply failed

A dead connection is not the only reason a post does not go out. A post the platform refused for its own reasons carries status: "failed" and the platform's message in error_message, after Chirpie has retried it three times. retry_count says how many attempts were made, so a post still scheduled with a non-zero count has missed at least one attempt and is waiting to try again.

See Posts for the full field reference and Scheduling for how retries work.