> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Sender pools: rotate outbound numbers and sender IDs

> Rotate outbound messages across a pool of Orbit numbers or sender IDs using sticky, round-robin, random, or geo-matched strategies for deliverability.

# Sender Pools

A sender pool is a named group of `from` addresses (E.164 numbers, short codes, or alphanumeric sender IDs) that Orbit picks from automatically at send time, instead of you hardcoding a single number on every send. Pools exist to solve two problems: spreading volume across more than one number so no single number gets overloaded or over-flagged by carriers, and picking a *local* number for a recipient so your messages don't arrive from an obviously foreign long code.

For the full request/response schema, see the [Sender Pools API reference](/api-reference/endpoints/messaging).

## When to use a pool

* **High-volume sending** — spread messages across several numbers so throughput and carrier reputation aren't concentrated on one sender.
* **Conversation continuity** — a support or marketing thread should always reply from the same number the contact already has in their inbox (`sticky`).
* **Local presence** — a recipient in France should see a French number, a recipient in Brazil a Brazilian one (`geomatch`).
* **Deliverability rotation** — swap out numbers whose reputation has degraded without changing anything in your send code.

## Creating a pool

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/messaging/sender-pools \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "US marketing rotation",
    "sender_dids": ["+14155550100", "+14155550101", "+14155550102"],
    "strategy": "sticky"
  }'
```

`sender_dids` accepts a mix of E.164 long codes, numeric short codes, and alphanumeric sender IDs in the same pool — useful if you operate in a market that requires an alphanumeric sender ID as a fallback alongside long codes. Up to 50 entries per pool, no duplicates.

## Selection strategies

| Strategy           | Behavior                                                                                                                                                                                             |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `sticky` (default) | The same recipient always gets the same sender from the pool, so a reply thread stays on one number. First contact with a recipient picks deterministically; the choice is remembered for next time. |
| `round_robin`      | Cycles through the pool in order, spreading volume evenly. Falls back to a deterministic pick if the counter is briefly unavailable, so a transient issue never blocks sending.                      |
| `random`           | Picks a sender at random on every send — no memory, no state.                                                                                                                                        |
| `geomatch`         | Matches the recipient's country to a sender in the pool from the same country. If no sender in the pool matches, falls back to `sticky` over the whole pool rather than failing the send.            |

Pick `sticky` for anything conversational (support, two-way SMS), `geomatch` for international campaigns where local presence matters, and `round_robin` or `random` for pure volume distribution with no continuity requirement.

## Previewing a selection

Before you route real traffic through a pool, preview which sender a given recipient would get — without committing any selection state (a preview never advances a round-robin counter or writes a sticky assignment):

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/messaging/sender-pools/pool_abc123/preview?recipient_phone=%2B33612345678" \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

A pool with no DIDs configured returns `422 SENDER_POOL_EMPTY` — add at least one DID before previewing or sending through it.

## Deliverability health

Each sender in a pool accumulates a health score from delivery outcomes. `GET /messaging/sender-pools/{id}/health` returns the per-member tier so you can see which senders are degraded before they cause delivery problems — the same signal Orbit's rotation scheduler uses to auto-swap a degraded sender for a warmed replacement.

## Endpoints

| Method   | Path                                          | Purpose                                  |
| -------- | --------------------------------------------- | ---------------------------------------- |
| `GET`    | `/api/v1/messaging/sender-pools`              | List pools                               |
| `POST`   | `/api/v1/messaging/sender-pools`              | Create a pool                            |
| `GET`    | `/api/v1/messaging/sender-pools/{id}`         | Get a pool                               |
| `PATCH`  | `/api/v1/messaging/sender-pools/{id}`         | Update a pool                            |
| `DELETE` | `/api/v1/messaging/sender-pools/{id}`         | Delete a pool                            |
| `GET`    | `/api/v1/messaging/sender-pools/{id}/preview` | Preview the sender a recipient would get |

## See also

* [Messaging credentials & services](/api-reference/messaging-credentials) — attaching a pool as a messaging service's sending identity
* [SMPP](/guides/smpp) — an alternative way to submit the sends a pool routes