> ## 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. # Number stuck in pending_compliance: why it happens and what un-sticks it > A purchased number shows pending_compliance while the carrier's compliance review (US 10DLC KYC and similar) is in flight. Read the state on the dashboard and API, know what can and cannot route to the number meanwhile, and what flips it to active. # Number stuck in `pending_compliance` You bought a number, the wallet was charged, and the number appears on your account, but its status badge reads `pending_compliance` instead of `active`. That state means the carrier-side compliance review for the number has not finished yet. This page explains what the state means, what works while it is set, and what moves the number to `active`. `pending_compliance` on a **number** is carrier review in flight. It is unrelated to the contact-erasure gates (`CONTACT_ERASURE_PENDING`, `ERASURE_COOLING_OFF_ACTIVE`) covered in [Pending compliance and erasure gates](/troubleshooting/pending-compliance-and-erasure-gates), which are about deleting contact data. It is also distinct from a purchase that failed outright: if the checkout returned `409` or `502`, use [Troubleshoot number purchase failures](/troubleshooting/numbers-provisioning-failed) instead. ## What `pending_compliance` means `pending_compliance` is one of the six number lifecycle statuses returned by the API (`pending_compliance`, `active`, `released`, `porting_in`, `porting_out`, `suspended`). The number exists on your account and the rental was charged, but the carrier has not finished the compliance review that regulation requires before the number can carry traffic. The review is most common on US 10DLC numbers, where the carrier vets the business identity and use case attached to the number; other regulated number types go through the same hold. The platform does not set a timer on the review. The row flips to `active` when the carrier reports the order activated through the order-status webhook; the flip only touches rows still in `pending_compliance`, so a number already `active` or `released` is never disturbed by a late webhook delivery. ## How to read the state * **Dashboard.** The Numbers page shows the status badge next to each number. While the review runs, the row reads `pending_compliance`. * **Single number.** `GET /api/v1/numbers/{id}` returns the number record; the `status` field carries the lifecycle state, and the record includes `provider_order_id` while a carrier order is open. * **Per compliance profile.** `GET /api/v1/compliance/compliance-profiles/{id}/numbers` lists the numbers bound to one profile, each with its carrier-review status (`pending_compliance` / `active` / `released`). Use it to see which of your DIDs depend on a given profile and where each one stands. The list is keyset-paginated with `limit` (1–200, default 50) and an opaque `cursor`. ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/numbers/num_abc123" \ -H "X-API-Key: dv_live_sk_..." curl "https://api.orbit.devotel.io/api/v1/compliance/compliance-profiles/cprof_abc123/numbers?limit=50" \ -H "X-API-Key: dv_live_sk_..." ``` ## What works while the number is pending Only a number whose status is `active` can be used as a dedicated sender. The pre-send eligibility checks select senders on `status = 'active'`, so a `pending_compliance` number is **not** an eligible dedicated sender. That is a soft limit, not a send outage: while you have no active dedicated number, outbound SMS falls back to the shared Devotel sender, so campaigns still send. Inbound is the stricter side. While the number sits in the carrier's regulatory hold, the carrier-side routing that delivers inbound SMS and calls to Orbit cannot be attached yet. When the carrier activates the number, Orbit re-arms those inbound attaches automatically, so inbound starts working after the flip without any action from you. Outbound through your dedicated number begins once the status reads `active`. ## What un-sticks it 1. **The carrier webhook does the flip.** There is no manual "approve" button: the order-status webhook from the carrier updates the row from `pending_compliance` to `active`, and stamps the number's metadata with the verification time so the audit trail shows when the carrier confirmed it. 2. **Give the review its window.** Carrier compliance review commonly takes one to three business days on US 10DLC numbers, and longer when the carrier requests more information. Inside that window, a pending status is normal and needs no action. The status field is the source of truth; re-polling `GET /api/v1/numbers/{id}` is how you watch it move. 3. **Check the compliance profile behind the number.** If the review stalls, the usual cause is the identity and documents the carrier is reviewing. Open the profile the number is bound to, confirm its documents are current, and resubmit if anything was rejected; [KYC submission and documents](/troubleshooting/kyc-submission-and-documents) covers the document requirements and the resubmission runbook. For a number that landed in `pending_compliance` without a profile attached, `POST /api/v1/numbers/{id}/attach-compliance-profile` attaches an approved profile and re-submits the pending carrier order; the carrier webhook later flips the row to `active`. The [number lifecycle reference](/numbers/lifecycle) documents the call. 4. **Escalate after the window.** If the status is still `pending_compliance` after three business days, or the profile shows a rejection you cannot resolve, open a support ticket with the number's E.164, its `id` (`num_…`), and the `provider_order_id` from the number record so support can chase the carrier order. ## Edge cases **Several numbers on one profile flip at different times.** The carrier reviews each order separately, so one profile can show a mix of `pending_compliance` and `active` numbers. That is expected; the per-profile numbers list shows where each DID stands. Numbers that already flipped work normally while their siblings finish review. **The profile was rejected.** If the carrier rejects the underlying compliance profile, fix the flagged documents and resubmit the profile, then re-attach it to the pending numbers (step 3 above). A resubmission restarts the carrier review clock, so allow the full window again before escalating. **Trust score while numbers are pending.** The [brand identity and trust score](/concepts/brand-identity-trust-score) rollup weighs verified, active posture; a number in `pending_compliance` has not contributed its carrier verification yet, so the score reflects it once the number is `active`. Pending numbers do not by themselves drop an otherwise healthy score. ## See also * [Number lifecycle](/numbers/lifecycle) — renew, release, reassign, reclaim, and the `attach-compliance-profile` call * [Troubleshoot number purchase failures](/troubleshooting/numbers-provisioning-failed) — `409` / `502` checkout failures, which are different from a pending review * [KYC submission and documents](/troubleshooting/kyc-submission-and-documents) — what the carrier reviews and how to resubmit * [Compliance profile glossary entry](/reference/glossary) — what a profile contains and the review lifecycle it follows * [Pending compliance and erasure gates](/troubleshooting/pending-compliance-and-erasure-gates) — the contact-erasure gates that share the "pending compliance" name but are a different mechanism This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.