Plans & quotas.
Two independent limits — a monthly request quota and a per-second burst ceiling — plus the feature flags each tier unlocks.
The limits
Every plan sets a monthly request quota and a burst ceiling. They are independent: you can be well inside your monthly quota and still be rate-limited for bursting, which is usually a client retry loop rather than real load.
| Plan | Requests / month | Burst / second | BYOI | TAXII subscribe |
|---|---|---|---|---|
free | 6,000 | 10 | — | — |
free_trial | 10,000 | 20 | — | — |
developer | 10,000 | 5 | yes | — |
standard | 50,000 | 10 | yes | yes |
pro | 50,000 | 30 | yes | yes |
Above these sit the workplace tiers — scale, platform and enterprise — which add sub-tenant management, SAML and custom contract terms. embed exists for single-product integrations.
Signup assigns free_trial: 10,000 requests a month at a 20/second burst, no card. Note that developer has the same monthly quota with a lower burst but adds bring-your-own-indicator submission — the tiers are not a strict ladder on every axis.
Feature gates
- BYOI — submitting your own indicators via
/v1/private/submit. - TAXII subscribe — pulling collections on a schedule rather than one-off exports.
- Webhooks — outbound delivery.
- Sub-tenants — nested organisations, on the workplace tiers.
Gates are enforced server-side in the action that performs the work, not by hiding the UI. See multi-tenancy for why that distinction is load-bearing.
Seeing consumption
GET /v1/usage reports your consumption against quota, and the portal surfaces the same numbers with a cost breakdown. The intent is that overage is never a surprise discovered at the end of a month.
Plans are per-organisation
A plan is a property of the organisation, so every member shares the quota — and changing it from any one member's row in the admin UI changes it for all of them. The admin surfaces spell out the affected member list before applying a change for exactly this reason.