After switching schedulers: how to reconnect your social accounts and check permissions before the first post

1. Preparation checklist

Grab org access for sign in, keep the account owner email or sign in flow handy, line up the media files you will test, and have one person ready to approve those OAuth prompts.

2. Reconnect accounts: generate a short-lived connect link (MCP)

Fire up the hosted MCP server at timetopost.co/mcp and use the connect_account_link tool to spin up a short lived social account connect link. The hosted server handles OAuth, so the browser pops open, you sign in, hit Approve access, and you are done. That is about as painless as OAuth ever gets, which feels like a small gift when you are already juggling tabs and mild existential dread.

The MCP docs note there is nothing to install, no API keys required, and the server runs under your own account permissions. It ends up a clean way to reconnect accounts after a scheduler switch without passing around long lived secrets.

3. Verify connected accounts and connection health (MCP)

Once reconnected, call the list_integrations tool to see the connected accounts. Check each integration’s reported connection health and account id so you can aim later calls at exactly the right ones.

This step matters because the REST API wants accountIds for specific connected accounts, and those ids only come from the integration list, not from guesswork and vibes.

4. Create or copy a personal API token if you will script checks (REST API)

If you plan to script any checks, create a personal API token in the dashboard under Settings → API. The docs say: "Tokens look like ttp_ followed by 48 hex characters, can optionally expire after 1-365 days, and are shown exactly once at creation. Only a hash is stored, so copy it immediately." That is from the REST API reference.

Pass the token as Authorization: Bearer ttp_xxx... on later API calls. The same reference points out the token carries your full account permissions, so treat it like a master key, not a sticky note.

5. Test media uploads with the presign flow before attaching files to posts (REST API)

Before you attach anything to a post, test the upload flow with POST /api/media/presign. The documented sequence is:

1. Request a presigned upload URL.
2. PUT the file to the returned uploadUrl.
3. Use the returned publicUrl in mediaUrls on your post.

The API reference says the body needs filename, contentType, and size, and that uploads get validated for type and size before a URL is issued. That catches the annoying stuff early, before your post is sitting there with a sad little broken attachment.

6. Create a draft aimed at the reconnected account to test publish permissions (REST API + Scheduling)

Use POST /api/posts without scheduledAt to save a draft targeted to the accountIds you got from list_integrations. Then confirm the resulting post has status draft via GET /api/posts.

That validates two useful things at once: the account id is accepted, and the publish permission for that connection is good enough to create the post. The scheduling docs say drafts are saved when you omit scheduledAt, and the REST API reference lists draft as a valid lowercase status.

7. Schedule a short future test and watch statuses (REST API + Scheduling)

Next, schedule the same post with a future ISO 8601 scheduledAt. The docs say the API rejects past times, so keep it in the future, even if your local clock is being dramatic.

To watch the lifecycle, poll GET /api/posts/:id or use the MCP get_post tool. The scheduling docs describe the usual path as DRAFT → SCHEDULED → PUBLISHING → PUBLISHED, and also note that multi-account posts can end up partial or failed.

8. Check scheduler health and delivery signals (MCP and Webhooks)

Call the MCP scheduler_status tool to confirm the timing worker is healthy, and if you want delivery notifications, set up a webhook endpoint for post.published and post.failed.

The webhook docs say TimeToPost sends signed JSON POSTs for those events, and that you can verify the signed deliveries yourself. That gives you a second signal besides polling, which is handy when you would rather let the system tap you on the shoulder than keep refreshing a page like a raccoon with a clipboard.

9. Worked example (hypothetical): reconnect a single X account, upload an image, create a draft, then schedule a test post

Hypothetical example only. Replace placeholders with your real values.

9.1 Generate a presigned media upload

curl -X POST https://timetopost.co/api/media/presign \
  -H "Authorization: Bearer ttp_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{
    "filename": "launch-test.jpg",
    "contentType": "image/jpeg",
    "size": 482133
  }'

Expected response shape, based on the docs:

{
  "success": true,
  "key": "...",
  "uploadUrl": "https://...",
  "publicUrl": "https://...",
  "expiresIn": 300
}

9.2 PUT the file to the returned uploadUrl

curl -X PUT "<uploadUrl>" \
  -H "Content-Type: image/jpeg" \
  --data-binary @/path/to/launch-test.jpg

9.3 Create a draft for the connected X account

Use the integration id you got from list_integrations as the account target.

curl -X POST https://timetopost.co/api/posts \
  -H "Authorization: Bearer ttp_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Reconnect test post for X",
    "accountIds": ["cmb8x2k4p0001..."],
    "mediaUrls": ["https://media.timetopost.co/uploads/launch-test.jpg"]
  }'

The docs say omitting scheduledAt saves a draft. A successful create returns 201 with the created post, and GET /api/posts should show it with status: "draft".

9.4 Schedule the same post in the near future

curl -X POST https://timetopost.co/api/posts \
  -H "Authorization: Bearer ttp_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Reconnect test post for X",
    "accountIds": ["cmb8x2k4p0001..."],
    "mediaUrls": ["https://media.timetopost.co/uploads/launch-test.jpg"],
    "scheduledAt": "2026-07-01T15:00:00.000Z"
  }'

Expected response shape, based on the documented example:

{
  "success": true,
  "post": {
    "id": "...",
    "status": "scheduled"
  }
}

Then poll GET /api/posts/:id or use MCP get_post until it moves through scheduled and publishing to published, or partial or failed if one of the selected accounts trips over its own shoelaces.

10. Quick pre-post sanity checklist

• Confirm the integration is listed and the connection health looks good.
• Confirm the draft saved.
• Confirm the media publicUrl works.
• Confirm scheduler_status is healthy.
• Confirm webhook or delivery monitoring is in place.

Links and further reading

• MCP overview, useful for connect_account_link, list_integrations, and scheduler checks.
• REST API scheduling walkthrough, useful for hands-on POST /api/posts examples and request shapes.