Rate limits

The endpoints that submit and read print orders have no rate limit in the application. Nothing in POST /api/print/orders, GET /api/print/orders/{code} or /api/account/api-key calls the limiter, so none of them can return 429. Other endpoints documented in this section — generation, printability, quoting from a stored model — do count your requests, per hour, per account.

The documented endpoints#

How the window works#

The limiter is a fixed window, not a rolling one. The window start is the clock floored to the window length, so an hourly limit resets on the hour for everybody at once, and a 15-minute limit resets at :00, :15, :30 and :45. Your first request does not start your own private hour.

Two consequences are worth designing around. A burst at the boundary is allowed: 20 generations at 10:59 and 20 more at 11:00 is 40 in two minutes without ever breaching a 20-per-hour limit. And an allowance spent early in a window is gone for the rest of it, however quiet the rest of that hour is — there is no drip of credit back.

• The counter key is a hash of the scope, the subject and the window start. Scopes are independent: spending your generation allowance leaves printability untouched.
• A request refused with 429 does not increment the counter, so hammering a closed door does not push the reset further out.
• A request that passes the limiter and then fails for its own reasons has still spent a slot. A 400 costs you one.
• Counters live in the same database the rest of the site uses, and the limiter fails closed: if that database is unreachable in production, requests are denied rather than waved through. A burst of 429s can therefore mean an outage rather than your traffic.

The 429 response#

HTTP/1.1 429 Too Many Requests
Retry-After: 3287
Content-Type: application/json

{ "error": "Generation limit reached. Please try again later." }

Retry-After is whole seconds until the window resets, never less than 1. It is a countdown to a fixed clock boundary, so it shrinks as the window ages — a 429 at 10:05 against an hourly limit reports about 3300 seconds, and the same 429 at 10:59 reports about 60.

Every limit in the codebase#

These are all of them, with the numbers as they are written in the routes. The first group is reachable by a customer; the second needs an operator account and is listed for completeness.

What actually constrains a print integration#

Since the print endpoints do not count your calls, the real ceilings are elsewhere, and they matter more than a request budget would.

• Money. Every accepted submission charges your card immediately. A runaway loop is a run of real charges and real orders, not a run of 429s.
• Farm capacity. Orders queue behind other orders on a small fleet in Austin. Submitting a hundred parts in a minute does not print them any sooner — see /docs/farm/capacity.
• Polling is cheap but not free. Prints run for hours, so a status poll every few minutes tells you everything a poll every second would.