When a plan lapses

Pre-release v1, published 2026-09-14. This page commits to the shape of the API, not to a date. We will build exactly what is documented here. The shape can still change until 2026-10-14; after that, changes follow Versioning and stability.

The banner comes off one page at a time as each route goes live. While it is here, build against the contract and assume the route is not callable yet.

Expiry happens in two stages. A plan that lapses does not cut a customer off at midnight.

StageWindowAPI writesEvents deliveredAI
Grace~1 day after expiry403 plan_inactive on create
DeactivatedAfter grace, unpaid403 on create

What keeps working

Reads (GET) keep working throughout. You can always see your own state, including robots, channels, usage and configuration, even when the plan is fully deactivated. A partner locked out of their own data during a billing dispute is a worse outcome than one who cannot create new robots.

During grace, events are still delivered but the AI has stopped. Your customers’ messages still reach you, so a human operator can answer them. Only the automated answers stop.

Nothing is deleted

Channels are disabled, not removed. Conversations, history, robots and automation rules all survive, and a disabled channel occupies no capacity.

Reactivating after a renewal

When the plan is renewed we re-enable the channels automatically and the robots resume with their data intact. Check the result rather than assuming it.

Re-enabling is checked against the renewed plan, so if the new plan is smaller than the old one, only as many channels as it allows come back. The rest stay disabled.

curl https://api-chat.parstechai.com/v1/robots/rbt_8fK2mQ/channels \
-H "Authorization: Bearer pk_live_xxxxxxxxxxxxxxxxxxxx"

Any channel still showing "is_active": false is one you must enable yourself, and you choose which:

curl -X PATCH https://api-chat.parstechai.com/v1/robots/rbt_8fK2mQ/channels/chn_3pQ7xL \
-H "Authorization: Bearer pk_live_xxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{"is_active": true}'

Order matters when you renew onto a smaller plan. Enable the pages that matter most first. Capacity counts enabled channels, so 403 capacity_exhausted arrives at the point the cap is reached — not before, and not in an order you control.

You can disable a channel deliberately too, with {"is_active": false}. It is the right way to pause a customer’s page while keeping their history, rules and configuration ready for when they return, without paying for a slot. See Enable or disable a channel.

What you should do

1

Handle 403 plan_inactive on writes

Surface it to your customer as a billing state rather than a system error. It is not transient and retrying will not help.

2

Keep reading

Your GET calls still work. Use them to show your customer exactly what is paused.

3

Do not delete and recreate

Deleting a robot to “reset” it destroys nothing we would have kept anyway, but it does lose the channel connection. That means asking the page owner to authorise again.

4

After renewal, confirm what came back

List your channels and enable any that are still is_active: false, most important first.