> ## 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.

# Regulated number-purchase compliance packets

> The documents and profile fields each regulated market (DE, GB, FR, BR, MX, IN, JP, FI, NL, SE) requires before a phone number activates, with a complete example compliance-profile payload per country.

# Regulated number-purchase compliance packets

In most countries a phone number activates the moment you buy it. In ten
markets the carrier reviews a compliance packet first: business documents,
identity proof, and a set of structured fields on your compliance profile.
This guide lists exactly what to prepare for each regulated market, so the
purchase preview passes on the first attempt instead of after a carrier
round trip.

## One registry, ten regulated markets

Buying a local, mobile, or toll-free number in **DE, GB, FR, BR, MX, IN,
JP, FI, NL, or SE** runs the regulated preflight: the buy flow (and
`GET /numbers/regulatory-preview`, documented on
[Regulatory Preview](https://docs.orbit.devotel.io/numbers/regulatory-preview.md)) evaluates the country
and number type against your organization's compliance profiles and
returns `compliance_profile_satisfies`.

* `compliance_profile_satisfies: true` — an approved profile already covers
  every required field and document for that market; the purchase
  proceeds like an unregulated one.
* `compliance_profile_satisfies: false` — complete the packet below for
  that country first. Buying anyway debits the number into
  `pending_compliance`, where it routes nothing until a satisfying
  profile is attached (see
  [Satisfy the preview before you buy](#satisfy-the-preview-before-you-buy)).

Every other country is unregulated for purchase: the preview returns
`unregulated: true`, no documents are requested, and the number activates
instantly. The ten regulated markets share one base packet and differ
only in the additions each market's section below names, so a profile you
built for one country is most of the way to any other.

## The shared base packet

Every regulated market collects the same base: two required documents
plus the business identity fields, and two prompted disclosure fields.

| Slot | Required | What it is |
| - | - | - |
| `business_doc` | Yes | Business registration certificate: certificate of incorporation, trade licence, or VAT certificate. |
| `address_proof` | Yes | Proof of the registered address, less than 90 days old: utility bill, bank statement, or lease agreement. |
| `business_name` | Yes | Registered business name. |
| `business_registration_number` | Yes | Registry number from the business document. |
| `vat_id` | No | VAT / tax ID, where your market issues one. |
| `address_street`, `address_city`, `address_postal_code`, `address_country` | Yes | The registered address, matching the address proof. |
| `address_region` | No | State / region / province. |
| `contact_name`, `contact_email`, `contact_phone` | Yes | The person the carrier may contact about the packet. |
| `website` | Prompted | Your business website. |
| `business_description` | Prompted | "Business use-case description (with sub-allocation disclosure)": how you will use the numbers, and whether you will sub-allocate them to your own end users or to third parties. |

The last two are optional in the strict sense but prompted on every
regulated purchase, and they are the two fields most often left blank.
Carriers that review regulated bundles return a "requirements partially
completed (3/6)" style rejection when the identity half of the packet is
fine but the website and use-case disclosures are missing, and that
rejection loops until the disclosures exist on the profile. Fill both on
every packet, even where the market's section below never mentions them.

Required versus prompted matters at the preview:
`compliance_profile_satisfies` enforces the required slots, so a profile
missing a required document or field fails the preview and blocks a clean
purchase. Prompted (optional) slots never block the preview; the wizard
prompts for them so the carrier's review does not stall on a partially
completed bundle.

## Germany (DE)

* **Document roles:** `business_doc` (required), `address_proof`
  (required), `id_proof` (required).
* **Structured fields:** the shared base packet; no market additions.
* **Accepted types:** `business_registration` or `vat_certificate` for
  `business_doc` (a Handelsregister extract); `utility_bill`,
  `bank_statement`, `lease_agreement`, or `proof_of_address` for
  `address_proof` (a Garanturkunde / rent registration counts as
  `lease_agreement`); `passport`, `id_card`, or `drivers_license` for
  `id_proof`.

```json theme={null}
{
  "business_name": "Beispiel Gerätebau GmbH",
  "business_registration_number": "HRB 12345 B",
  "vat_id": "DE123456789",
  "address_street": "Musterstraße 12",
  "address_city": "Berlin",
  "address_region": "Berlin",
  "address_postal_code": "10115",
  "address_country": "DE",
  "contact_name": "Katrin Vogel",
  "contact_email": "k.vogel@example.de",
  "contact_phone": "+493012345678",
  "website": "https://www.example.de",
  "business_description": "Support and delivery-notification lines for our own customers. Numbers are not sub-allocated to third parties."
}
```

The upload-to-attachment walk for the German address proof (Garanturkunde
as `lease_agreement`) is in
[The KYC Identity Model](https://docs.orbit.devotel.io/compliance/kyc-identity-model.md).

## France (FR)

* **Document roles:** `business_doc` (required), `address_proof`
  (required), `id_proof` (required).
* **Structured fields:** the shared base packet; no market additions.
* **Accepted types:** `business_registration` for the Kbis (the registry
  extract issued by the Greffe du Tribunal de Commerce);
  `proof_of_address` or `utility_bill` for the justificatif de domicile;
  `passport`, `id_card`, or `drivers_license` for `id_proof`.

```json theme={null}
{
  "business_name": "Société Exemple SAS",
  "business_registration_number": "RCS Paris 123 456 789",
  "vat_id": "FR12345678901",
  "address_street": "12 Rue de la Paix",
  "address_city": "Paris",
  "address_postal_code": "75002",
  "address_country": "FR",
  "contact_name": "Camille Laurent",
  "contact_email": "c.laurent@example.fr",
  "contact_phone": "+33123456789",
  "website": "https://www.example.fr",
  "business_description": "Appointment reminders for our own clients in France. Numbers are not sub-allocated to third parties."
}
```

The Kbis and justificatif uploads are worked end-to-end in
[The KYC Identity Model](https://docs.orbit.devotel.io/compliance/kyc-identity-model.md).

## United Kingdom (GB)

* **Document roles:** `business_doc` (required), `address_proof`
  (required), `id_proof` (prompted).
* **Structured fields:** the shared base packet; no market additions.
* **Accepted types:** `business_registration` or `vat_certificate`
  (Companies House certificate); `utility_bill`, `bank_statement`,
  `lease_agreement`, or `proof_of_address`; `passport`, `id_card`, or
  `drivers_license`.

The UK carrier requirement is one compound ask: a local
government-issued ID/passport copy **or** a company registration
certificate. Orbit therefore prompts both inputs. Attach the company
registration as `business_doc`, or satisfy the identity branch with a
passport or national ID as `id_proof`; either proof completes the
compound requirement, while `address_proof` stays required alongside.

```json theme={null}
{
  "business_name": "Example Trading Ltd",
  "business_registration_number": "01234567",
  "address_street": "12 Example Street",
  "address_city": "London",
  "address_postal_code": "EC1A 1BB",
  "address_country": "GB",
  "contact_name": "Alex Hughes",
  "contact_email": "a.hughes@example.co.uk",
  "contact_phone": "+442012345678",
  "website": "https://www.example.co.uk",
  "business_description": "Order updates and customer service callbacks for our own customers. Numbers are not sub-allocated to third parties."
}
```

## Japan (JP)

* **Document roles:** `business_doc` (required), `address_proof`
  (required), `id_proof` (prompted).
* **Structured fields:** the shared base packet; no market additions.
* **Accepted types:** `business_registration` (a certified registry
  extract, e.g. a tokibo now); `utility_bill`, `bank_statement`,
  `lease_agreement`, or `proof_of_address`; `passport`, `id_card`, or
  `drivers_license`.

Japan runs the same compound rule as the UK: the carrier accepts either
the company registration or a government-issued ID/passport, so
`business_doc` is required and `id_proof` is prompted as the
substitutable branch.

```json theme={null}
{
  "business_name": "Exemple Kabushiki Kaisha",
  "business_registration_number": "0100012345678",
  "address_street": "1-2-3 Marunouchi, Chiyoda-ku",
  "address_city": "Tokyo",
  "address_postal_code": "100-0005",
  "address_country": "JP",
  "contact_name": "Sato Ken",
  "contact_email": "k.sato@example.jp",
  "contact_phone": "+81312345678",
  "website": "https://www.example.jp",
  "business_description": "Customer support lines for our own users in Japan. Numbers are not sub-allocated to third parties."
}
```

## Finland (FI)

* **Document roles:** `business_doc` (required), `address_proof`
  (required), `id_proof` (prompted).
* **Structured fields:** the shared base packet; no market additions.
* **Accepted types:** `business_registration` or `vat_certificate` (YTJ
  trade register extract); `utility_bill`, `bank_statement`,
  `lease_agreement`, or `proof_of_address`; `passport`, `id_card`, or
  `drivers_license`.

Finland runs the same compound rule as the UK and JP: company
registration or government-issued ID, with `business_doc` required and
`id_proof` prompted as the alternative branch.

```json theme={null}
{
  "business_name": "Esimerkki Oy",
  "business_registration_number": "1234567-8",
  "address_street": "Mannerheimintie 12",
  "address_city": "Helsinki",
  "address_postal_code": "00100",
  "address_country": "FI",
  "contact_name": "Matti Virtanen",
  "contact_email": "m.virtanen@example.fi",
  "contact_phone": "+358912345678",
  "website": "https://www.example.fi",
  "business_description": "Service calls and booking confirmations for our own customers. Numbers are not sub-allocated to third parties."
}
```

## Netherlands (NL)

* **Document roles:** `business_doc` (required), `address_proof`
  (required), `id_proof` (prompted).
* **Structured fields:** the shared base packet; no market additions.
* **Accepted types:** `business_registration` or `vat_certificate` (KvK
  extract); `utility_bill`, `bank_statement`, `lease_agreement`, or
  `proof_of_address`; `passport`, `id_card`, or `drivers_license`.

The Netherlands runs the same compound rule as the UK, JP, and FI:
company registration or government-issued ID, with `business_doc`
required and `id_proof` prompted as the alternative branch.

```json theme={null}
{
  "business_name": "Voorbeeld B.V.",
  "business_registration_number": "KvK 12345678",
  "address_street": "Damrak 12",
  "address_city": "Amsterdam",
  "address_postal_code": "1012 JK",
  "address_country": "NL",
  "contact_name": "Daan de Vries",
  "contact_email": "d.devries@example.nl",
  "contact_phone": "+31201234567",
  "website": "https://www.example.nl",
  "business_description": "Delivery coordination for our own customers in the Netherlands. Numbers are not sub-allocated to third parties."
}
```

## Brazil (BR)

* **Document roles:** `business_doc` (required), `address_proof`
  (required), `id_proof` (required), plus the `authorization` role
  (prompted): a signed letter from a company director authorizing the
  contact person, uploaded as `power_of_attorney` (or `other`).
* **Structured fields:** the shared base packet plus `cnpj` (required),
  the business registry number issued to every Brazilian legal entity.
* **Accepted types:** `business_registration` or `vat_certificate`;
  `utility_bill`, `bank_statement`, `lease_agreement`, or
  `proof_of_address`; `passport`, `id_card`, or `drivers_license`;
  `power_of_attorney` or `other` for the authorization letter.

```json theme={null}
{
  "business_name": "Exemplo Tecnologia Ltda",
  "business_registration_number": "NIRE 35212345678",
  "cnpj": "12.345.678/0001-90",
  "address_street": "Av. Paulista 1000",
  "address_city": "São Paulo",
  "address_region": "SP",
  "address_postal_code": "01310-100",
  "address_country": "BR",
  "contact_name": "Ana Souza",
  "contact_email": "a.souza@example.com.br",
  "contact_phone": "+551112345678",
  "website": "https://www.example.com.br",
  "business_description": "Customer service numbers for our own customers in Brazil. Numbers are not sub-allocated to third parties."
}
```

Attach the authorization letter whenever the carrier review asks for
one; the wizard prompts the role alongside the required `cnpj` field.

## Mexico (MX)

* **Document roles:** `business_doc` (required), `address_proof`
  (required), `id_proof` (required).
* **Structured fields:** the shared base packet plus `rfc` (required),
  the tax identifier SAT issues to every registered entity. The RFC
  travels as profile data, not as a document.
* **Accepted types:** `business_registration` (the acta constitutiva or
  registry extract), `vat_certificate`; `utility_bill`,
  `bank_statement`, `lease_agreement`, or `proof_of_address`;
  `passport`, `id_card`, or `drivers_license`.

```json theme={null}
{
  "business_name": "Ejemplo Comercial S.A. de C.V.",
  "business_registration_number": "Folio 123456",
  "rfc": "ECV123456XX1",
  "address_street": "Av. Reforma 100",
  "address_city": "Ciudad de México",
  "address_postal_code": "06600",
  "address_country": "MX",
  "contact_name": "Luis García",
  "contact_email": "l.garcia@example.mx",
  "contact_phone": "+525512345678",
  "website": "https://www.example.mx",
  "business_description": "Order confirmations for our own customers in Mexico. Numbers are not sub-allocated to third parties."
}
```

## India (IN)

* **Document roles:** `business_doc` (required), `address_proof`
  (required), `id_proof` (required).
* **Structured fields:** the shared base packet plus `gstin` (required)
  and `pan` (required). Both travel as profile data; the preview flips
  `compliance_profile_satisfies` only once both are present.
* **Accepted types:** `business_registration` (certificate of
  incorporation), `vat_certificate`; `utility_bill`, `bank_statement`,
  `lease_agreement`, or `proof_of_address`; `passport`, `id_card`, or
  `drivers_license`.

```json theme={null}
{
  "business_name": "Example Technologies Private Limited",
  "business_registration_number": "CIN U72900KA2020PTC123456",
  "gstin": "29ABCDE1234F1Z5",
  "pan": "ABCDE1234F",
  "address_street": "100 MG Road",
  "address_city": "Bengaluru",
  "address_region": "Karnataka",
  "address_postal_code": "560001",
  "address_country": "IN",
  "contact_name": "Priya Sharma",
  "contact_email": "p.sharma@example.in",
  "contact_phone": "+918012345678",
  "website": "https://www.example.in",
  "business_description": "Customer support and OTP lines for our own users in India. Numbers are not sub-allocated to third parties."
}
```

## Sweden (SE)

* **Document roles:** `business_doc` (required), `address_proof`
  (required), `id_proof` (required).
* **Structured fields:** the shared base packet; no market additions.
* **Accepted types:** `business_registration` or `vat_certificate`
  (Bolagsverket extract); `utility_bill`, `bank_statement`,
  `lease_agreement`, or `proof_of_address`; `passport`, `id_card`, or
  `drivers_license`.

Two Sweden-specific conditions: the address proof must be dated within
90 days of submission, and the end user must be physically present in
Sweden at purchase time. Presence is recorded as an attestation during
the purchase flow; no separate document is needed for it.

```json theme={null}
{
  "business_name": "Exempel Aktiebolag",
  "business_registration_number": "556677-8899",
  "address_street": "Sveavägen 12",
  "address_city": "Stockholm",
  "address_postal_code": "111 57",
  "address_country": "SE",
  "contact_name": "Elsa Andersson",
  "contact_email": "e.andersson@example.se",
  "contact_phone": "+46812345678",
  "website": "https://www.example.se",
  "business_description": "Customer service numbers for our own customers in Sweden. Numbers are not sub-allocated to third parties."
}
```

## Satisfy the preview before you buy

Work the packet until the preview passes, then buy:

**1. Upload the documents to your KYC library**

`POST /compliance/documents` with the library `type`, the
`country_code`, and the file. You get a `doc_…` ID per upload; the
accepted `type` values and the role-to-type mapping are on
[KYC Documents](https://docs.orbit.devotel.io/compliance/documents-kyc.md).

**2. Attach each document by ID and role**

`POST /compliance/compliance-profiles/:id/documents` attaches a
`doc_…` ID to the profile under its role (`business_doc`,
`address_proof`, `id_proof`, `authorization`). Create the profile
with `use_case: phone_number_purchase` and the market's country
code if you don't have one yet.

**3. Set the structured fields**

`PUT /compliance/compliance-profiles/:id/data` with the base fields
plus your market's additions (`cnpj`, `rfc`, `gstin` + `pan`), and
the two prompted disclosures, `website` and
`business_description`.

**4. Re-run the preview until it flips**

Call `GET /numbers/regulatory-preview` with the country and number
type after each update. When every required slot is filled and the
attached documents are unexpired,
`compliance_profile_satisfies` returns `true` and the purchase
activates normally.

If you buy with `compliance_profile_satisfies: false` anyway, the number
is debited but held at `pending_compliance`: it routes nothing until an
approved profile is attached, and the carrier sets a verify-by window on
the order. If the window expires while the number still waits, the
carrier can auto-release it and return the inventory, so the number is
lost as well as inert. The window and the recovery path are covered on
[Regulatory Preview](https://docs.orbit.devotel.io/numbers/regulatory-preview.md) and
[Number Lifecycle](https://docs.orbit.devotel.io/numbers/lifecycle.md).

## Rejected packet?

A carrier rejection names the requirement it could not satisfy. Read
the reason against this page's per-market section, fix the one slot it
names (an expired address proof and a missing sub-allocation disclosure
are the two common ones), and re-submit; the fix loop, including how to
swap documents without breaking other consumers of the same `doc_…`
ID, is on
[Carrier Rejection Feedback](https://docs.orbit.devotel.io/compliance/carrier-rejection-feedback.md) and
the
[KYC Profile Submission Runbook](https://docs.orbit.devotel.io/compliance/kyc-profile-submission-runbook.md).

## Your packet, your accuracy

Orbit prompts for the packet, carries it to the carrier, and enforces
the purchase gate; the documents and data are yours. Carriers and
regulators in each country grant final approval, and the accuracy of
what you submit, and renewing documents before they lapse, stays with
your organization. This page documents what the platforms collect and
how the gates behave; it is not legal advice and is not a compliance
guarantee for any market.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.