Plans, limits and changing plan
Four plans. Every limit is visible in the API before you hit it, every refusal names the capability that caused it, and changing plan is a conversation rather than a checkout.
Last updated
What each plan includes
| Free | Hobby | Starter | Pro | |
|---|---|---|---|---|
| Price | $0 | $9 / month | $29 / month | $99 / month |
| API requests / month | 10,000 | 100,000 | 500,000 | 5,000,000 |
| Rate limit | 5 / s | 10 / s | 30 / s | 100 / s |
| Projects | 1 | 2 | 5 | 25 |
| Posts | 100 | 1,000 | 25,000 | Unlimited |
| API keys | 2 | 5 | 20 | 100 |
| Members | 1 | 2 | 10 | 50 |
| Full-text search | — | Yes | Yes | Yes |
| Media uploads | — | Yes | Yes | Yes |
| Bring your own MongoDB | — | — | Yes | Yes |
| Per-endpoint analytics | — | Yes | Yes | Yes |
| Over the request limit | Refused | Refused | Refused | Billed as overage |
What happens at a limit
| Limit | Response | Detail you get |
|---|---|---|
| Requests per second | 429 RATE_LIMIT_EXCEEDED | policy, limit, retryAfterSeconds |
| Requests per month | 429 QUOTA_EXCEEDED | The capability and the period |
| Posts, projects, keys, members | 403 ENTITLEMENT_REQUIRED | capability, limit, current |
| A feature the plan lacks | 403 ENTITLEMENT_REQUIRED | capability, currentPlans, upgradeUrl |
A count limit refuses at the limit — not one past it, and not one short. If your plan allows two keys, the third request is the one refused, and it tells you the number.
Changing plan
There is no card on file and no checkout. You ask for a plan, somebody reads the request, and the limits move. We invoice separately. That is a deliberate choice while the platform is young: a payment provider is a compliance surface and a webhook consumer, and neither is worth carrying before there is anybody to bill.
Ask
From the Plan screen in the dashboard, or from the API. Only the workspace owner can — choosing what the company pays for is an owner’s decision, and an agent token can never hold it.
Examplebash curl -X POST https://api.cmskite.com/v1/plan-requests \ -H "authorization: Bearer $ACCESS_TOKEN" \ -H "x-tenant-id: $WORKSPACE_ID" \ -H 'content-type: application/json' \ -d '{ "planCode": "blog_pro", "note": "Traffic doubled this month." }'Wait, with everything still working
Asking is not getting. Your current plan keeps working exactly as before while the request is open, and you can withdraw it. One open request at a time.
It takes effect
Once approved, your subscription moves in a single transaction and every credential you hold is resolving the new limits within about five seconds. You see the decision and the reason in your plan history.
Downgrading never deletes anything
Move from Pro to Free with 900 posts and you keep all 900. They stay readable, editable and served. The next create is refused; nothing that exists is removed, archived or hidden.
The same rule holds if an invoice goes unpaid: access degrades to the free plan after a grace period rather than stopping. We never revoke read access to data a customer created. A platform that deletes content on downgrade is a platform nobody can safely try.