Plans and feature access

Every account sees the same tool list, so tools/list is stable and safe to cache. You don't need to negotiate capabilities per user.

Access to the underlying features is subject to their availability in the account's subscription plan, and is enforced when a tool is called — not when the tool list is fetched. Visit the Pricing page for more information.

The error comes from the service behind the tool, so its exact shape depends on which service that is. Both of these are real responses to a publish call from an account whose plan didn't cover the feature.

Publishing an automation, where the plan's action allowance is exhausted:

{
  "code": "FEATURE_UNAVAILABLE",
  "description": "Payment is required to perform this action",
  "help": "Upgrade your plan to access this feature",
  "details": [
    { "code": "FEATURE_UNAVAILABLE", "field": "actions-executed" }
  ]
}

Publishing a form that uses a field type the plan doesn't include:

{
  "code": "PAYMENT_REQUIRED",
  "description": "The account is not authorised to use some of the features",
  "details": [
    {
      "code": "NOT_ALLOWED_VIDEO-ANSWERS",
      "description": "The 'video-answers' feature can not be used by this account"
    }
  ]
}

Two things to take from these:

• Branch on the top-level code, never on the prose. FEATURE_UNAVAILABLE and PAYMENT_REQUIRED both mean "this account's plan doesn't cover it". The description and help strings are written for a model to relay to the user and may change — and help isn't always present.
• details says what is gated, as a field or a NOT_ALLOWED_* code. That's the part worth surfacing to your own users: "video answers isn't on your plan" is actionable in a way that "payment required" isn't.

Gating is per feature, not per tool. The same tool can succeed for one account and fail for another — and can fail for one form and succeed for another on the same account.