Plans, Limits and Refusals

Nautilus is priced by monthly active users, not by API requests. There is no monthly request quota: calling the API more often costs nothing extra. (Short per-minute rate limits, such as the 60 a minute on Gate's identity endpoints, protect the service from runaway loops; they are separate from plan limits and answer 429 with Retry-After.) What each plan limits is a short list of things you can count — active users, Relay messages, Clockwork jobs and, on Free, projects — and this page says what each limit is, what happens at it, and exactly what your code receives.

The prices and the same table are on the pricing page; the dashboard's Billing page shows where you stand this month.

Plans

Support: on Pro, replies come during business hours; on Advanced, within one business day. Contract is a dedicated installation, hosted and run by Verne, with volumes, price, terms and response times agreed in the contract.

The audit log has windows of its own, shorter than the history above, because it holds data about people (who signed in, from which address): see Audit Log. The account owner can shorten the window; nobody can lengthen it past the plan's.

Pro and Advanced are the names of the plans everywhere: the API ("plan": "pro"), the dashboard and the checkout.

Automatic deletion of inactive accounts is included from Free, in part: on Free you can switch on the rule that deletes accounts that were never confirmed; Pro and above also have the reminder to confirm, the role deadlines and the deletion of accounts that have gone unused. Nothing is on until you switch it on. See Automatic Deletion of Inactive Accounts.

What counts as an active user

An active user is an end user who signs in to your application at least once in a calendar month (UTC), by any method — password, one-time code, social login or Telegram. However often they sign in, they are one active user for that month.

• A user you create through the API (POST /v1/gate/identities) who never signs in is not counted.
• The count is per calendar month, in UTC, and starts again at 00:00:00 UTC on the 1st. Earlier months are kept, so the history of your count survives.
• It is counted per project and added up per account. A person active in two of your projects is one active user for the account, so the per-project figures can add up to more than the account total.
• Deleting an end user removes them from the current month's count.

When you go over the active-user limit

• Sign-in is never blocked. Anyone who already has an account can always sign in, on every plan, however far over the limit you are.
• You are notified by email at 80 % and at 100 % of the limit, once each per month.
• After you pass the limit you have one full calendar month to move to a higher plan.
• After that month, if you are still over the limit, only new registrations are refused, until you move to a higher plan or a month ends at or under the limit. Sign-in, and everything else, keeps working.
• There is no per-user charge for going over.

Exactly, month by month. The month in which the number of active users first becomes greater than the limit is the month of excess; being exactly at the limit is not exceeding it.

For example, on Free (limit 1,000): the 1,001st person signs in on 12 October, so October is the month of excess; November is the month to move up; on 1 December new registrations are refused if November ended above 1,000.

Moving to a higher plan lifts the refusal at once. Moving to a lower plan is judged the same way, from the month the excess is first seen, so it does not block registrations immediately.

If the gateway cannot determine your account's state, it lets the registration through rather than guessing: a few people over the limit is cheaper than lost sign-ups.

The refusal: 402 ACTIVE_USER_LIMIT_REACHED

Only the creation of a new end user is refused, and always with the same response, wherever the person tries to register:

{
  "error": {
    "code": "ACTIVE_USER_LIMIT_REACHED",
    "message": "This account is over its monthly active-user limit and the grace month to move up has ended, so new end users cannot be created. People who already have an account can still sign in. Move to a higher plan in the dashboard, or write to support, to lift it.",
    "request_id": "req_…",
    "plan": "free",
    "limit": 1000,
    "current": 1043,
    "sign_in": "unaffected"
  }
}

It is a 402, not a 429: it does not lift with time, it lifts when you move to a higher plan, so retrying it later does nothing. There is no Retry-After header.

Where you can meet it:

Not refused: sign-in by any method (including of an existing person through all the paths above), recovery, verification, reading, updating or deleting a user.

Relay: messages a month

Relay counts the messages you send in a calendar month (UTC): a successful POST /v1/relay/messages. Reading and listing messages is not counted. At the limit, a new send is refused:

HTTP/1.1 429 Too Many Requests
Retry-After: 1209600

{
  "error": {
    "code": "RELAY_MESSAGE_LIMIT_REACHED",
    "message": "You have sent the 10000 messages the Free plan includes this month. New messages are accepted again when the month ends (see Retry-After) or move to Pro for a higher limit.",
    "request_id": "req_…",
    "plan": "free",
    "limit": 10000,
    "current": 10000
  }
}

Retry-After is the number of seconds until 00:00:00 UTC on the 1st of next month, when the count starts again, so a client that waits that long and retries does the right thing. Moving to a higher plan lifts it at once. You are emailed at 80 % and 100 % of the Relay allowance, as for active users. A tenant on Contract has no Relay limit.

Clockwork and projects: 402 UPGRADE_REQUIRED

Clockwork limits how many jobs exist at once (the table above), not how often they run. Creating a job over the limit, or resuming a paused recurring job, is refused with 402; so is creating a second project on Free:

{
  "error": {
    "code": "UPGRADE_REQUIRED",
    "message": "The Free plan allows 10 active recurring jobs and you already have 10. Delete or pause a job, or upgrade to Pro (1000 allowed).",
    "request_id": "req_…",
    "plan": "free",
    "kind": "cron",
    "limit": 10,
    "current": 10
  }
}

kind (cron or delayed) is present on Clockwork refusals. On Advanced, where the next plan is Contract and is not self-service, the code is JOB_LIMIT_REACHED; for a project it is PROJECT_LIMIT_REACHED. Like the active-user refusal it is a 402: waiting does not lift it, and a 402 must not be retried. See Clockwork plan limits.

Nothing is deleted when you move to a smaller plan: what you have keeps running, and only new jobs, resumes and projects are refused until you are back under the limit.

The one thing that stops is an automatic deletion rule your new plan does not include: it is switched off, its settings are kept, and we email the account's address once to say which ones. Moving back up does not switch it on again.

Billing responses

Two 402 responses are about payment, not limits, and only settling the account lifts them. They are answered to API use that is not an end user signing in, such as a Relay send or a call to the Gate Admin API:

Signing in is never blocked for billing reasons. For a suspended account or an unpaid renewal, your end users can still sign in and your backend can still verify the result: Passepartout login/start, login/status and tokens/introspect, and Gate's login, session and token endpoints, answer as usual. The only refusal on the sign-in path is ACTIVE_USER_LIMIT_REACHED for a new person, which is a separate rule (see above).

The packs of extra requests that the earlier pricing sold are discontinued. The old dashboard route that started their checkout (POST /dashboard/billing/checkout) answers 410 Gone with the code PACKS_DISCONTINUED; it is not part of the API-key interface. A plan is bought from the dashboard's Billing page.

Summary of refusals