> ## 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.
# Reading the subprocessor registry
> How to read and use Orbit's public subprocessor registry — what each entry means, how it feeds GDPR Art. 28 and SOC 2 reviews, and how to subscribe to change notices.
# Reading the subprocessor registry
Orbit publishes the full list of third parties that process platform data
as a public, open surface — no form, no NDA. You can read it rendered on
the [subprocessors page](https://orbit.devotel.io/en/subprocessors) or
inside the [Trust Center](https://orbit.devotel.io/en/trust) (both render
the same list), and you can pull it into your own vendor register before
a questionnaire arrives. This page is the reader's guide: what each row
actually tells you, how the registry maps onto your GDPR and SOC 2
answers, and how to stay notified when it changes.
The registry is a disclosure, not a configuration. It describes the
platform Devotel operates; there is no tenant-side toggle that changes
which subprocessors apply to your workspace.
This page describes the platform's published posture. It is **not legal
advice.** Confirm your role-based obligations (controller/processor) and
Art. 28 wording with qualified counsel.
***
## What each row means
Every entry in the registry carries the same fields. When you copy it
into your vendor register or answer "who are your vendor's
subprocessors", map them like this:
| Field | What it tells you | How to use it |
| ------------------------ | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | The legal entity of the third party | The counterparty you list in your Art. 30 register of processing activities |
| **Purpose** | The specific platform function the vendor serves (e.g. LLM inference, cloud compute, payment processing) | The scope of processing you can name in the questionnaire answer — not "everything" |
| **Region** | Where the data is stored or processed | The residency answer for that data class. For messaging (email, SMS, WhatsApp, RCS) and audit data this is the only residency surface — the [voice region pin](/compliance/voice-data-residency) covers voice data and nothing else |
| **Data categories** | The coarse classes that flow to the vendor: `account`, `content`, `metadata`, `billing`, `telemetry`, `auth` | What actually leaves the platform for that vendor — e.g. billing goes to the payment processor, telemetry to the monitoring vendors |
| **Inbound-only badge** | Marks carriers engaged for inbound termination only | Outbound voice and SMS traffic exits only through Devotel's own wholesale softswitch; inbound-only carriers never see outbound traffic |
| **Website / vendor DPA** | Links to the vendor's public site and, where offered, the vendor's own data-processing terms | The covering agreement you can cite alongside the registry entry |
Each subprocessor is bound by a Data Processing Agreement or equivalent
contractual terms, and is permitted to process customer data only as
necessary to deliver the listed purpose.
***
## Where it lands in a GDPR answer
You will meet the registry in three recurring compliance artefacts:
1. **GDPR Art. 28.** When you (as controller) engage Orbit as your
processor, Devotel engages these subprocessors under the general
written authorisation clause in the [Data Processing
Agreement](/compliance/data-processing-agreement). The published
registry is the current list that clause refers to, and the advance
notice of additions or removals is handled by the change hooks below.
2. **GDPR Art. 30 register.** Read the registry before you write Orbit
into your own register of processing activities: vendor name, purpose,
region, and data category per entry. The [privacy
register](/compliance/privacy-register) guide covers the register
itself.
3. **Security questionnaires and SOC 2 reviews.** The registry is open
evidence — buyers can clear the "vendor's subprocessors" rows without
an NDA before the gated material (counter-signed DPA, answered
questionnaires) is requested. See the [Trust Center evidence
pack](/compliance/trust-center-evidence-pack) for the full generation
sequence.
See the [GDPR posture guide](/compliance/gdpr-posture-guide) for the
wider controller/processor split; the [Legal index](/legal/) keeps the
map of which document binds which party.
***
## Subprocessor changes and notice hooks
The registry is live: entries are added, replaced, and removed as the
platform's provider inventory changes, and each change is recorded in a
public change history on the [subprocessors
page](https://orbit.devotel.io/en/subprocessors) alongside a last-updated
stamp. Change entries are one of `added`, `replaced`, `removed`,
`published`, or `reviewed` — a `reviewed` entry records a periodic
re-verification of the whole register against the provider inventory, so
a refreshed last-updated stamp has an audit trail explaining it.
Notice of additions and removals goes out by email before the change
takes effect, consistent with the DPA's subprocessor-clause mechanics.
The self-serve signup is a section on the subprocessors page; behind it
sit three public endpoints documented under the [Public
API](/api-reference/endpoints/public):
* `POST /api/v1/public/subprocessor-subscriptions` — registers the email
address; returns an empty `data` envelope and starts a double-opt-in
confirmation.
* `GET /api/v1/public/subprocessor-subscriptions/confirm` — the link in
the confirmation email; carries a one-time token and activates the
subscription.
* `GET /api/v1/public/subprocessor-subscriptions/unsubscribe` — the link
in every notice email; carries a one-time token and removes the
subscription.
The worked call, exactly as the Public API entry documents it:
```bash cURL theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/public/subprocessor-subscriptions" \
-H "X-API-Key: dv_live_sk_your_key_here" \
-H "Content-Type: application/json" \
-d '{}'
```
```json 200 theme={null}
{
"data": {},
"meta": {
"request_id": "req_01HZQX4E7JQ4M2E2H2DM9XE5FJ",
"timestamp": "2026-08-26T12:00:00.000Z"
}
}
```
An empty `data` payload here is the expected success shape — the
subscription stays pending until the confirmation link is opened, and the
email address is the only payload the form accepts. Until you complete
confirmation, no notices are sent.
***
## Related references
The registry rendered alongside SOC 2 control mappings and
downloadable agreements.
Which surface answers each channel's residency question.
The controller/processor split and the register this list feeds.
Which document governs which relationship, and who owns each
obligation.