Rate Limits

The Textingline API enforces per-key rate limits to ensure fair usage and platform stability.

Limits by endpoint

Shared rate-limit buckets

The contact-management endpoints share two pooled buckets rather than per-endpoint limits:

• contactApiRead (150 requests / 60 seconds) — pooled across every read endpoint in the Contact Management section: GET on /contacts/by-phone/{phoneNumber}, GET on /groups, GET on /groups/{id}, and GET on /contacts/custom-fields/schema.
• contactApiWrite (150 requests / 60 seconds) — pooled across every write endpoint in the same section: POST / PATCH on /contacts/by-phone/{phoneNumber}, POST / DELETE on /contacts/by-phone/{phoneNumber}/groups/{groupId}.

If you saturate one bucket with one endpoint, subsequent calls to a different endpoint in the same bucket also hit the 429 — design your CRM-sync or batch-import code accordingly. The headers and Retry-After response are the same as for the messaging endpoints (described below).

Rate limit headers

Every API response includes headers that tell you your current rate limit status:

Exceeding the limit

When you exceed the rate limit, the API returns a 429 Too Many Requests response with an additional Retry-After header:

{
  "code": 33002,
  "message": "Rate limit exceeded",
  "status": 429,
  "moreInfo": "https://docs.smsfactory.com/docs/error-codes"
}

Daily messaging quota

In addition to per-second rate limits, each account has a daily messaging quota that limits the total number of messages you can send per day. When exceeded, the API returns error code 33012:

{
  "code": 33012,
  "message": "Daily messaging quota reached",
  "status": 429,
  "moreInfo": "https://docs.smsfactory.com/docs/error-codes"
}

Carrier message limits

If you send over 10DLC (US A2P long codes), the mobile carriers apply their own limits on top of the ones above. When you register a brand and campaign, each carrier assigns that brand an allowance — how much it may send, and how quickly. The allowance reflects how established and trusted the brand is, and it is the carriers' main lever for keeping unwanted A2P traffic off their networks.

These limits belong to the carrier, not to the Platform. They apply to the brand as a whole, so every number and campaign registered under it draws on the same allowance.

Your allowance is used as fast as the carriers accept messages. A broadcast larger than what remains will therefore partly succeed: the recipients it covers are sent, and the rest fail with carrier_limit_reached. That error names the carrier, the limit that was hit, and when the allowance next resets.

Send again after the reset, split large sends across days, or raise your brand tier with the carrier to increase the allowance.

Opt-out confirmations and other single messages are never blocked by a carrier allowance.

Best practices

• Monitor the headers. Check X-RateLimit-Remaining before sending batches to avoid hitting the limit.
• Implement backoff. When you receive a 429, wait for the Retry-After duration before retrying.
• Use broadcasts or batches for bulk sends. Instead of sending 10,000 individual messages, use a single broadcast (same message to all) or batch (unique message per recipient) request to stay well within rate limits.
• Spread requests over time. If sending many individual messages, space them evenly across the rate limit window.