Why the caps exist
All identities send and receive on a shared Sente-operated domain, under one email-provider account. Email deliverability is reputation-based and the reputation is shared: one tenant sending spam gets the domain flagged, and a flagged domain means verification emails stop landing for every customer. The caps are the blast-radius guard for that shared resource — they are not a growth lever. The same logic applies to runs: abusive registration volume against third-party apps degrades the platform for everyone. See the Acceptable use policy.Plan tiers
A run is one registration or login attempt driven by the Sente browser. Failed runs never
count against your quota — you are not charged capacity for our failures.
Design-partner pilots are invoiced manually — if the tiers above don’t fit, email
support@sente.run.
Platform-wide daily brakes
In addition to plan caps, two platform-wide per-organization brakes apply regardless of plan (current defaults):
These exist so a runaway agent — yours or anyone’s — can’t burn a large volume in one burst. If a
legitimate workload needs more, email support@sente.run.
Limit error codes
When you hit a cap, the API returns a structured error with acode and the limit that was hit:
Example response:
Waiting on the inbox is free and uncapped in these terms:
GET /messages/wait (long-poll for an
OTP or magic link) does not consume run or send quota.Operational limits worth knowing
- Blocked runs hold for ~10 minutes. When a run blocks for a human (CAPTCHA, SMS 2FA, manual
step), it waits about 10 minutes for someone to take over via the live view, then fails with
BLOCKED_TIMEOUT. See Runs and human takeover. - One live session per identity. Requesting a session while another is live or a run is in
flight returns
409(SESSION_STALE/SESSION_PENDING) with the blockingrunId. See Sessions.
Related
- Acceptable use policy — what the caps are protecting.
- Security model — where credentials live and who can read them.
- API overview — error shape and auth.