This is not in your plan

You reached a page or an API route and were told it is not part of your plan. As of 2026-09-27 this is no longer something the ordinary console navigation walks you into — a module your plan does not include is removed from the menu entirely, not shown dimmed with a padlock. You most likely got here from an old bookmark, a link from before a downgrade, or by building directly against the API. This article explains what the refusal actually says, and one specific piece of advice: the plan it suggests upgrading to is a real, correct plan, but it is not always the cheapest way to get what you want.

What the refusal actually says

If a request reaches a module your licence does not include, it is refused with HTTP status 402 Payment Required and this body:

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "error": "tier_upgrade_required",
  "feature": "pam",
  "upgrade_to": "professional",
  "required_tier": "professional",
  "plan_name": "Complete",
  "capability": "pam",
  "available_as": "add_on",
  "add_on": "pam",
  "add_on_tier": "starter",
  "add_on_annual_price_eur": 15,
  "add_on_monthly_price_eur": 18
}

The fields worth reading are error, which is the stable part of the contract, and feature/capability, which name the module or narrower capability that was wanted — for a whole module, one of pam, siem or xdr. required_tier exists only for older software and always carries the same value as upgrade_to. A useful detail if you are building against the API: the console treats a 403 as an entitlement problem only when the body carries tier_upgrade_required, so that an ordinary role denial still surfaces as an ordinary error rather than as an upgrade prompt. Copy that behaviour.

Which plan actually includes what

So in plain terms: Core already includes endpoint protection and SIEM alongside identity — nothing is identity-only any more. On both Core and Protect, the only things locked are privileged access and Compliance Autopilot, and neither requires an upgrade: both are sold as add-ons you can turn on directly from Settings → Plan & add-ons. Sentinel-Q, our investigation and action capability, is included on every paid plan from Core upward — Free does not include it at all — and what changes between tiers is how much it is allowed to do on its own, not whether you have it.

Exactly which parts of the product are gated

Three, and only three. The gate runs as the very first thing on every API request and matches on the address:

• Anything under /api/v1/organizations/{your organisation}/pam/ requires the privileged-access module.
• Anything under .../siem/ requires log management.
• Anything under .../xdr/ requires endpoint protection.

Identity is not gated at all — every plan includes it, so there is nothing to check. The AI capability is gated separately, by a different mechanism, because its requests carry your organisation in the session token rather than in the address. If you are technically minded and building against the API, note that the three prefixes carry a trailing slash, so a request to .../pam with nothing after it does not match a rule and passes through.

One design decision is worth naming because it is easy to mistake for a bug. A request to a module you do not hold is refused, not answered with an empty list. An empty list is indistinguishable from a clean estate, and a security product must never let a commercial boundary look like an all-clear. If you ask for your privileged sessions and you do not have the privileged-access module, you get a refusal — you never get the reassuring answer none.

This is a commercial boundary, not a lock

We would rather be plain about the strength of this mechanism than let you infer more from it than it delivers. The gate is careful in the ordinary case: a tenant with no licence record on file is refused, which is the safe direction. But all three variants of the check pass the request through when they cannot work out which organisation is asking — because authentication and tenancy are enforced separately, elsewhere, and a licence check has no business being the thing that stops an anonymous request.

That is a defensible design, and it means the entitlement gate is a commercial control rather than a cryptographic one. Modules you have not bought are not encrypted away from you; they are refused. If your interest in this is compliance rather than commerce — for instance, demonstrating that a subsidiary cannot reach another subsidiary's data — the mechanism you want is tenancy and the region binding, not the plan gate. Where your data lives covers that.

The other payment-required refusal: you are out of seats

A second, different 402 exists and it is not about modules. When you invite somebody and your plan's person limit is already reached, you get:

HTTP/1.1 402 Payment Required

{"error":"feature_not_available","feature":"max_users","required_tier":"professional"}

Two things to know. The error name is different from the module gate's — feature_not_available rather than tier_upgrade_required — so if you are automating, match on the feature field rather than on the error name. And required_tier here is hardcoded to professional regardless of how many seats you actually need. Under the current plans this refusal can only actually happen on Free, whose 10-person ceiling is the only hard membership limit left in the product — Core, Protect and Complete all carry no seat cap at all, so any one of them removes the limit, not just Complete. Ignore the hardcoded suggestion and pick whichever paid plan otherwise fits your modules and budget, starting at Core.

The seat count is the number of people who are members of your organisation, and the limit is only applied to growth — nothing is disabled retroactively if a plan change lowers your ceiling below your current headcount. Seats and how they are counted has the detail.

Two things the plans promise that nothing yet measures

Being unflattering about our own commitments is more useful to you than the alternative. Two sets of numbers appear on the plans and are not enforced by anything:

Allowances

Log volume per person per day, endpoints per person, non-human identities, AI investigations per person per month. These are published as commitments, not as live usage — a daily usage snapshot records what your tenant actually has, but the published allowances are not yet billed against it, and exceeding one is not refused. Treat them as a description of the size of organisation each plan is designed for.

The autonomy ceiling

Each plan names how much Sentinel-Q may do without asking. Free does not include Sentinel-Q at all. From Core, it builds a fully specified fix and waits for one click of approval (L3 Recommend). From Protect, it can act on its own inside an envelope you declare, opt-in per action class (L4 Act) — upgrading never turns this on by itself; every new autonomy option still starts at recommend until you switch it on. See Autonomy tiers explained and What Sentinel-Q is allowed to do.

What to do next

1. 1

   Read the module's own page before you buy it

   Settings → Plan & add-ons describes what each module does before you turn it on. Choosing which modules to turn on is the honest version — including which ones are worth having for an organisation of forty people and which are not.

2. 2

   Check the plan table above, not the error message

   The upgrade_to value in the refusal is unreliable in both directions.

3. 3

   Ask for a quote

   Published prices are indicative. A firm figure, including whether an annual minimum applies to you, comes from us — Contact.

4. 4

   If you see 500 `license check failed`, that is ours

   It means we could not read your licence at all, not that you lack one. Retry, and tell us if it persists.

• Changing your plan — how an upgrade or downgrade actually takes effect.
• Plans and what each includes — the full comparison.
• Insufficient permissions — if the refusal is a 403 rather than a 402, it is your role and not your plan.