402:
What stops and what does not
This is the part worth building around, because it is not a blanket block.
Only the two things that start or continue a conversation with a customer are
refused. Everything your team needs to coordinate keeps working, so a
workspace that cannot reply yet can still triage, assign, and leave notes for
each other on the thread.
Reads are never blocked. An integration that syncs tickets into your own
system sails through a quota block without noticing.
Paid plans stop too
Every plan stops at its limit, paid ones included. There was a period where paid plans were waved through on the promise of an overage charge. That charge was never built, so the waving through was just a hole. Now the behaviour is the same everywhere: the limit is the limit.Handling a 402
Do not retry it. Nothing changes until the period resets or someone upgrades, so a retry loop will simply keep failing.402 as a signal to
queue the work locally and stop calling. Coming back after the reset with a
backlog is fine, especially with
an idempotency key on each one so a replayed queue does
not double up.
Seeing it coming
The dashboard warns as a workspace approaches its limit, and owners get an email before it bites. There is no API for usage yet.A
402 is a billing state. It is not 403, because your credentials are
fine and you are permitted to do this. Something that treats 403 as “log
in again” would send an integration round an auth loop over an unpaid invoice.