Changing your plan
Upgrading, downgrading, what happens to your data and to a module you lose, and the exact 402 you will see afterwards. Figures are provisional.
Moving between plans is mostly uneventful, and the two things that surprise people are both worth reading in advance: what a request to a module you no longer have looks like, and what happens to the data that module was holding. This article covers both, plus the billing mechanics underneath.
Upgrading
Core, Protect and Complete are not self-serve today. Self-serve checkout for a paid plan is switched off while it is finished — Settings → Plan & add-ons shows the plans and their prices, but the action next to a plan you don't hold reads "Talk to us" rather than "Upgrade", and email to [email protected] is how it actually happens right now. The hosted-checkout mechanism (Stripe, EU VAT calculated at the point of sale, add-ons like Privileged Access at €15 per privileged person per month with no separate checkout flow) exists in the product and is what we use to set your subscription up on our side; it is just not something you complete yourself yet.
There is no trial that starts itself. If you want to try a plan before committing to it, say so when you email us — that is a conversation, not a form field, while self-serve checkout is off.
Enterprise is the one plan you cannot buy at a checkout. It is priced on application, so there is no price to send. Pressing Upgrade on it does not open a payment page — the console tells you to get in touch. That is not a sales gate for its own sake: at that size the questions that shape the deployment — dedicated cell sizing, migration from an existing collector — are not ones a checkout page can ask. The dedicated cell itself is in the EU; there is no other region to choose.
Once the change is applied, the module set, identity limit and retention window on your licence are taken from the plan catalogue rather than typed in. That matters because the old approach — hardcoded values in the billing code — had already drifted from the published plans, which is how a customer came to be told they had 180-day retention and no AI while their own licence said 365 days and AI enabled.
Downgrading, and what you lose
A downgrade changes three things on your licence: which modules are enabled, how many identities you may have, and how far back a log search may look. It does not delete anything.
The identity limit is not applied retroactively. If you drop to a plan whose limit is below your current membership count, nobody is disabled and nobody is signed out — but the next invitation fails. The full behaviour, including the exact error, is in Seats, and how they are counted.
The retention change is the one people most often misread. Retention is applied as a clamp on how far back a log query may reach, not as a deletion job. Dropping from Complete to Protect narrows your search window from 365 days to 90; it does not erase the older events, which remain in storage and simply stop being returned. Going back up widens the window again. We are telling you that because it is true today, not because it is a guarantee — a purge job is a reasonable thing for us to build, and if we build it the older data will genuinely go. Do not plan a compliance position on the current behaviour. Retention settings has the detail.
A module you lose behaves differently again. Nothing belonging to it is deleted — your vaulted credentials, your detection rules, your alerts and your collected logs all stay where they are — but the routes that reach them start refusing. That refusal has a specific shape, and it is the next section, because it is the string a customer searches for at the worst possible moment.
The entitlement gate, and the error it returns
An entitlement gate sits in front of the API and checks, before anything else runs, whether your licence includes the module a request is aimed at. It gates exactly three path prefixes — privileged access, log collection and detection, and endpoint detection and response — and nothing else. Identity and access is not gated at all, because every plan includes it.
When the gate refuses, the status is 402 Payment Required and the body looks like this. The example is a request to a privileged-access route on a licence that does not include the module:
HTTP/1.1 402 Payment Required
Content-Type: application/json
{"error":"tier_upgrade_required","feature":"pam","upgrade_to":"professional","required_tier":"professional","capability":"pam","available_as":"add_on","add_on":"pam","add_on_tier":"starter"}error is the stable part of that contract and feature/capability tell you which module or narrower capability was wanted — for a whole module, one of pam, siem or xdr. required_tier is kept only for older clients and carries the same value as upgrade_to.
There is a second, different 402 in the product for the seat ceiling, using the key feature_not_available. The two shapes are inconsistent with each other. If you are matching on these in a script, match on feature.
A third response exists for the case where we could not read your licence at all, rather than read it and found the module missing:
HTTP/1.1 500 Internal Server Error
{"error":"license check failed"}That one is ours to fix. Send it to us with a timestamp; it is not something you can resolve by changing plan.
One matching quirk that occasionally produces a confusing support thread: the gated prefixes carry a trailing slash, so a request to a bare module root with no further path segment does not match any rule and passes through. It will usually fail for some other reason a moment later. If you see one privileged-access call behaving differently from all the others, that is the likely cause.
The billing mechanics
Payment is handled by Stripe. We do not hold your card. Five things are worth knowing about the plumbing.
- Checkout
- A hosted subscription checkout, one line item, with automatic tax enabled for EU VAT and one-stop-shop handling. Your organisation is attached to the session so that the resulting subscription can be matched back to you without anybody typing an account number.
- The customer portal
- A hosted portal session for changing your payment method and reading your billing history at source. It is the right place for anything about the card rather than about the plan.
- Invoices
- Kept as a local projection so the subscription screen can render without a round trip to Stripe on every page load. Each carries its number, status, amount due and paid, currency, billing period and links to the hosted invoice and the PDF. The list returns 50 by default and 200 at most.
- Downloading an invoice
- The invoice list on the Subscription screen has a PDF column with a Download link on every invoice whose PDF is ready, which opens the invoice document directly. A dash in that column means there is no PDF yet rather than that something has gone wrong — a very recent invoice may still be a draft at the payment provider, and the link appears once it is finalised. The hosted invoice link beside it works either way.
- Cancellation
- Sets the subscription to end at the end of the period you have paid for, and answers
{"status":"cancel_at_period_end"}. Nothing stops immediately. What happens afterwards is in Leaving, and taking your data with you.
Every one of those routes checks that the organisation you are acting for is the organisation on your session before it does anything, and a request with no organisation on it is refused. Cancellation additionally checks that the specific subscription being cancelled belongs to that organisation — proving you may act for the organisation says nothing about which subscription identifier you passed.
Billing actions are administrator-only. Spending money is not an operational task, and the permission split reflects that. See Who can see and do what.
Checking the change actually landed
Open your subscription summary
It reports your tier, seats used against seats available, enabled modules, retention days, whether AI is enabled, your current period end and a subscription status. If the tier, modules and retention match what you bought, the licence is right — that is what this screen is for. Treat the status indicator itself as informational rather than as a live health check on your billing: if you are in any doubt about whether a payment has gone through, check with support or read your billing history at source in the customer portal.
Look at the drift list on your plan view
Your organisation's plan view shows your licence next to the catalogue entry for your tier, and names every field where they disagree — identity limit, retention days, AI flag, enabled modules. An empty drift list is the answer you want. A populated one is the whole diagnosis, and it is what to paste into a ticket.
Try the thing you bought
If you upgraded for privileged access, open the vault. A 402 with
"feature":"pam"means the licence did not pick up the module; anything else means it did and something separate is wrong.Wait five minutes before escalating
The licence cache has a five-minute life. A screen that has not caught up is the most common false alarm here.
If your console and your invoice disagree, that is a defect we want to hear about, not something for you to reconcile. Drift is reported rather than hidden precisely so that somebody looking at a console that contradicts an invoice can see which side is wrong.
What to do next
- Check the module table in The plans, and what each one includes before you change anything, and ignore what the 402 suggests.
- If a downgrade is about cost rather than fit, ask us first. None of the self-serve plans carries an annual floor any more — only a small per-head minimum — so removing an add-on you barely use is often a better answer than dropping a whole module.
- If you are leaving rather than downgrading, read Leaving, and taking your data with you before you cancel, because the export is smaller than most people expect.