Rate limit

Every interface worth calling has one, and a script that ignores it looks exactly like an attack. Knowing whose count you spend, and what a wait means, is what keeps automation working.

A rate limit is a ceiling on how many calls one caller may make in a window before the answer becomes a wait.

What a ceiling actually counts

A rate limit is a promise about speed rather than about totals. It says how many calls one caller may make inside a window, and what comes back on the call after that.

The point is not to slow honest work down. It is that one loop with a mistake in it cannot take the service away from everybody else.

Where ours stand

One ceiling stands in front of the whole cloud interface, and tighter ones stand in front of the routes worth attacking.

Every route
A shared ceiling per minute, applied by a single guard rather than remembered route by route.
Signing in
Tighter than the rest, because this is the surface every password guesser knocks on.
Handing a session to the app
Tighter still. The code that carries a sign in from the site into the program is meant to be used once.
Sending the confirmation mail again
The tightest of all, because that button reaches somebody else's inbox.
The support form
Counted over a longer window, so a typo is forgiven and a script is not.

One guard in front of everything

A ceiling remembered route by route is a ceiling somebody forgets on the next route. This one is declared once and stands in front of every address by default.

Whose count it is

A ceiling counts callers, and a caller here is an address. Two scripts on one machine share a count, and the same script split across two machines does not.

Behind a front door that writes the visitor's address into a header, only the hops we actually sit behind are believed. An address written at the front of that header changes nothing.

Trusting a header too much is how a ceiling disappears

If every entry in that header were believed, a guesser would add one line and start a fresh count on every attempt. Believing too few entries only counts several people as one.

What a wait looks like in code

Over the ceiling the answer is a plain too many requests rather than the work you asked for. It is a wait and not a verdict, and the next window starts clean.

Back off and try again with a growing gap. Our own sender treats that answer from your server as worth repeating, so a busy receiver is not mistaken for a dead one.

Three limits that behave differently

Three different things in this product get called a limit, and they behave in three different ways.

The daily pace of a profile
It counts the pages a profile opened, colours a bar and never blocks an action. The decision stays with you.
How many profiles are open
This one says no for real. Past the number the next window does not open until you close one, and the number is yours to raise.
How often you may call
The rate limit on this page. It shapes the speed of calls and says nothing about how much work your plan allows.

The interface on your own machine

The automation interface running on your computer has no ceiling of its own. It trusts the machine it runs on, and the token plus its refusal to answer a web page carry the whole load there.

That is a trade with a cost, and the cost is yours: a runaway loop on your own machine is something you notice and stop.

What this does not do

There is no per key quota. The count follows the address a call comes from, so two keys used from one machine spend one count between them.
The interface on your own computer has no ceiling of its own, which is why the token and the refusal to talk to a page do all the work there.
The daily pace counter refuses nothing. It counts pages opened, colours a bar and leaves every decision with the person reading it.
A ceiling per minute is not a quota on work. How many profiles and how many team seats you have is a different number kept in a different place.

Check it

Every claim above points at a file you can open and a stand that runs against a real server.

A ceiling stands in front of every route by default, and the sign in surface carries a tighter one: apps/server/src/app.module.ts · apps/server/src/auth/auth.controller.ts
The count follows the caller's own address behind a proxy, and a forged header does not move it: apps/server/test/предел-попыток.js · apps/server/test/подбор-пароля.js
The form that reaches a person is counted over a longer window: apps/server/src/support/support.controller.ts · apps/server/test/поддержка.js
The interface on your own machine has a token gate instead of a ceiling: apps/desktop/src/lib/local-api.js · apps/desktop/test/local-api-gate.js

Questions

What do I do when I am told to wait?: Pause and try again with a growing gap rather than immediately. A tight retry loop looks the same as the attack the ceiling was put there to survive.
Is the count against my key or against me?: Against the address the call came from. A key names the account and the ceiling names the caller, and those are two different questions.
Are sign in attempts counted separately?: Yes, and more tightly than ordinary routes. Guessing a password is the one thing a stranger can try without an account of their own.
Can a header make me look like a new caller?: No. Only the hops the server actually sits behind are believed, so an address added at the front of that header is read as a claim rather than a fact.
Does my whole team share one ceiling?: Only where you share an address. The count follows where a call comes from rather than which account it belongs to.

Next to this

Build against ceilings you can read

Every ceiling here is one line in one file, and the stands holding them run against a real server rather than a description of one.

Download ARMANOS The API in full