What to Export Before Canceling Your Scheduler Subscription

What to export before you cancel

Export anything you might need for continuity, verification, or reuse before you cancel. Cancellation can cut off access to data you still want, so yeah, this part is boring but genuinely useful.

If you want the underlying product docs handy while you do this, the scheduling docs explain how post states work, and the API reference shows what you can pull programmatically.

Export your scheduled and draft posts first

Start with the current queue. Save drafts and scheduled items before you cancel, because those are the easiest things to lose track of during a migration. Nobody remembers the one half-finished caption until it is gone, then suddenly it was very important.

TimeToPost’s scheduling docs spell out the lifecycle clearly: “DRAFT Saved without a publish time. Drafts never publish on their own.” and “SCHEDULED Has a future publish time. The background scheduler will pick it up when scheduledAt arrives.” That is the stuff you want to export first, because it tells you exactly what is still waiting to go out.

Export post history for records and reuse

Next, export your post history so you keep a record of what was published, what failed, what only partially succeeded, and what got canceled. That gives you something to verify against later, and it also helps when you need to rebuild a queue without guessing.

The API reference says GET /api/posts lists posts for the active organization, and each post includes id, content, platforms, status, scheduledAt, publishedAt, and mediaUrls.[^api-posts] That is enough detail to reconstruct a basic history export, or at least to know which items need follow-up.

Export media assets and their public URLs

Do not forget the media. If your posts use attached images or other files, save those assets separately, along with any public URLs or file references you need to recreate the posts elsewhere.

If you uploaded media through TimeToPost, the API flow returns a publicUrl after a direct upload, and that is the URL you reference in POST /api/posts mediaUrls.[^api-media] In other words, keep the file and keep the URL. Future-you will absolutely ask for both.

Export connected account details and identifiers

Export the list of connected accounts or integration IDs too. When you switch setups, you will want the same destinations available again, not a mystery pile of “which account was this?”

TimeToPost’s API reference says POST /api/posts can target specific accountIds, and those are the integration ids returned by GET /api/integrations.[^api-posts] Preserve those identifiers so you can rebuild the setup without reconnecting everything from scratch and playing identifier whack-a-mole.

Export approval and webhook settings if your workflow depends on them

Only export approvals if your account actually uses them, and only export webhooks if another system depends on those status updates. If nobody is listening downstream, copying webhook settings is just paperwork with better branding.

TimeToPost’s webhooks docs say the platform can send events such as post.scheduled, post.published, post.failed, draft.approved, and draft.rejected, so those endpoint settings should be copied before cancellation if your automation depends on them.[^webhooks] If you are planning to automate the migration or hand it to an agent, the MCP overview is useful because it shows how TimeToPost works through an MCP client instead of raw clicking.

Worked example: a simple pre-cancel export checklist

Here is a hypothetical migration that keeps the pain contained.

1. Export a CSV of scheduled posts, including drafts and items already queued.
2. Save the media links used by those posts, along with the actual image files if you still need them.
3. Copy the connected account IDs from GET /api/integrations so the same destinations can be rebuilt later.
4. Record any webhook endpoint URLs and the events they listen for, especially if another system uses those updates.
5. Store all of that in one folder before canceling the subscription.

After the switch, the saved CSV becomes the rebuild list, the media links point to the right assets, the account IDs let you target the same destinations with POST /api/posts, and the webhook notes help you reattach the automation. That is the entire trick, really. Export first, cancel second, and avoid making your future self do archaeology.

What to check before you click cancel

Before you click cancel, verify that you have saved the queue, media, account references, and any automation hooks you depend on. Then check that the exported files are actually stored somewhere safe and accessible.

Once those pieces are confirmed, canceling is a lot less dramatic. The scheduler can go away, but your history, assets, and integration details should not vanish with it.

[^api-posts]: TimeToPost API docs [^api-media]: TimeToPost API docs [^webhooks]: TimeToPost webhooks docs