Regions and data residency

Every tenant is pinned to exactly one region. It is chosen at tenant creation and is not a setting you can flip afterwards - moving is a migration.

Region	API base URL
eu	https://api.nextpki.com and https://api.nextpki.de
us	https://api.nextpki.com

Regions do not replicate

Certificate data, observations, renewals and audit records stay in the region where they were created. There is no cross-region replication, which is the point: for EU customers, data residency is a purchasing requirement rather than a feature.

Consequences for an integration:

• Call the endpoint for your tenant’s region. Calling the wrong one does not leak anything; your tenant simply is not there, and you get 401 or 404.
• A multi-region estate means multiple tenants, each with its own tokens. There is no single call that spans them - aggregate on your side.
• Sensor endpoints are region-specific too, both for registration and reporting. See network requirements.

Which endpoint for EU tenants

api.nextpki.com and api.nextpki.de both serve the EU region. The .de name exists because some German customers prefer it in documentation and contracts. They are equivalent; pick one and stay with it so certificate pinning and firewall rules stay simple.

What this does not cover

Region pinning describes where NextPKI holds your data. It says nothing about:

• Where your certificates are issued. A public CA operates its own infrastructure wherever it operates it. If issuance jurisdiction matters, choose a provider accordingly - several EU-based, ETSI-qualified authorities are in the registry.
• Where your certificates are deployed. That is your infrastructure.
• Sub-processors. Named in the data processing agreement, not here.

For contractual detail - processing agreements, sub-processors, deletion - ask for the DPA rather than relying on this page.