Documentation
Sign inGet started
Commencer
Guides
Référence API
SDK et CLI
Base de connaissances
Changelog

Abuse & compliance

Bird is shared infrastructure: every sender's traffic travels over the same platform, and the reputation of that platform with mailbox providers and carriers is what gets everyone's messages delivered. Abuse protection exists to keep that shared reputation healthy; it is what makes your own deliverability possible. This page explains the channel-agnostic model. The concrete signals and thresholds for each channel live in the per-channel pages, starting with email.
What you can and cannot send is governed by Bird's Acceptable Use Policy; the acceptable use summary is a plain-language walkthrough of it. This page covers how Bird detects and responds when sending goes wrong, whether through abuse or honest mistakes like a stale mailing list.

The trust & safety pipeline

Bird monitors account and sending activity for abuse across the platform, and may throttle, pause, or place activity under review when something looks wrong. Detection adds no latency to your API calls: a legitimate integration never gets slower because monitoring exists, and if Bird does intervene, the action is visible (a throttle, a pause, a review notice), never a silent drop.

Throttling and pausing

Sending behaviour feeds a per-workspace reputation on each channel. Healthy traffic (low bounce rates, low complaint rates, recipients who asked to hear from you) keeps reputation high and sending unrestricted. Bad behaviour degrades it, and Bird responds proportionally:
  • Throttling slows your sending rate while the problem signal persists, giving you time to correct course without a hard stop.
  • Pausing halts sending on the affected channel when the signal crosses the line from degraded to harmful, for example a bounce rate that indicates a purchased or badly stale list.
The signals that drive this, and the indicative thresholds, are channel-specific: see Abuse & compliance · Email for the email model. Throttling and pausing protect your sender reputation as much as Bird's; continuing to send traffic that mailbox providers are rejecting makes recovery harder, as explained in the deliverability guide.

Protections you encounter directly

Most abuse protection is invisible when your traffic is healthy. A few controls are visible by design, because they sit on public surfaces that attackers probe:
  • CAPTCHA on public account flows. Signup, password reset, and the flows that resend account emails require a CAPTCHA challenge before the backend does any work. This is what keeps signup automation and bulk account creation from consuming the platform.
  • Failed-authentication throttling. Repeated failed logins and bad API keys are throttled per source; legitimate use is unaffected.
  • SMS passcode country allowlist. One-time passcodes over SMS are sent only to phone numbers in a supported set of countries; enrolling or verifying with a number outside it is rejected with a 422 (PhoneCountryNotAllowed). This closes off SMS pumping, the fraud scheme that triggers OTP sends to premium-rate numbers.
  • Per-phone and per-IP limits. OTP sends and verification attempts are rate-limited per phone number and per source IP, with progressive delays on repeated failures.
These controls protect your account as well as the platform: an attacker who can burn your SMS budget or brute-force your login is your problem before it is Bird's.

Next steps