Environments & base URLs
4 minute read
DigiCert® provides both production and demo environments across four geographic regions. Each API call starts with a region-specific hostname (base URL), followed by a predictable versioned path.
Tip
See Platform IP addresses and URLs for a complete list of protocols, hostnames, and IP addresses.| Environment | Purpose |
|---|---|
| Demo | Safe testing, proof-of-concepts |
| Production | Live operations |
Region and hostname matrix
Make sure to use the appropriate hostname based on your regional requirements.
| Region | Demo hostname | Production hostname | Notes |
|---|---|---|---|
| United States (US) | demo.one.digicert.com | one.digicert.com | Default region; lowest latency for the Americas |
| Japan (JP) | demo.one.digicert.co.jp | one.digicert.co.jp | Japanese data residency. |
| Switzerland (CH) | demo.one.ch.digicert.com | one.ch.digicert.com | Swiss data sovereignty; strict privacy laws |
| Netherlands (NL) | demo.one.nl.digicert.com | one.nl.digicert.com | EU-only data storage (GDPR) |
| Australia (AU) | demo.one.au.digicert.com | one.au.digicert.com | Australian data residency. |
Note
Add theclientauth. prefix to any of the above hostnames when you authenticate with a client certificate. For example, clientauth.demo.one.digicert.com. See Authentication for details on using mTLS.Base URL pattern
Every DigiCert® ONE API follows this structure:
https://{hostname}/{product}/api/v{n}/{resource}
| Segment | Description | Examples |
|---|---|---|
{hostname} | DigiCert ONE hostname | one.digicert.comdemo.one.digicert.comone.digicert.co.jp |
{product} | DigiCert ONE product-specific path segment | account (Account Manager)certificate-authority (DigiCert Private CA)mpki (Trust Lifecycle Manager)signingmanager (Software Trust Manager)devicetrustmanager (Device Trust Manager) |
api/v{n} | API version; most products are v1 and follow this convention. Device Trust Manager uses nested versioning for some endpoints, for example /{resource}/api/v{n}. | api/v1api/v3/{resource}/api/v{n}* |
{resource} | Specific endpoint path | usersdivision/enrollment/{enrollment_id}/status/certificate-configuration-service/api/v2/certificate-policy* |
* Examples specific to API endpoints.
API endpoints by product
| Product | Path segment | Full example |
|---|---|---|
| DigiCert® Account Manager | account | https://one.digicert.com/account/api/v1/user |
| DigiCert® Private CA | certificate-authority | https://one.digicert.com/certificate-authority/api/v1/ca |
| DigiCert® Software Trust Manager | signingmanager | https://one.digicert.com/signingmanager/api/v1/keypairs |
| DigiCert® Document Trust Manager | documentmanager | https://one.digicert.com/documentmanager/api/v1/credentials/list |
| DigiCert® Device Trust Manager | devicetrustmanager | https://one.digicert.com/devicetrustmanager/api/v4/devices |
| DigiCert® Trust Lifecycle Manager | mpki | https://one.digicert.com/mpki/api/v1/certificate-owners |
Working with environments
Start with demo
Demo is perfect for:
- Integration development and testing.
- Training new team members.
- Validating workflows before production.
- Load testing (within reason).
# Example: List certificates in Trust Lifecycle demo environment
curl -X GET \
-H "x-api-key: YOUR_DEMO_KEY" \
https://demo.one.digicert.com/mpki/api/v1/certificate-owners
Promote to production
When moving from demo to production, make sure you:
Create new credentials: Demo API keys don’t work in production.
Update base URLs: Change only the hostname portion;
demo.one.* to one.*. Paths stay identical.Verify firewall rules: Your outbound IP list might differ between environments.
Test incrementally: Start with
GET calls, then progress to POST/PUT once quotas and roles are validated.# Demo environment
BASE_URL="https://demo.one.digicert.com"
# Production environment (only hostname changes)
BASE_URL="https://one.digicert.com"
# Your code stays the same
curl -X GET \
-H "x-api-key: $API_KEY" \
"$BASE_URL/account/api/v1/users"
Network considerations
IP allowlisting
If your infrastructure requires IP allowlisting, make sure you understand the following:
- Current IP ranges are available at Platform IP addresses and URLs.
- Consider using FQDN-based rules instead of IPs when possible.
TLS requirements
- Minimum TLS version: 1.2
- Recommended: TLS 1.3
- Required for mTLS: Valid client certificate chain
- Certificate validation: DigiCert® validates the full certificate chain
Self-hosted deployments
For on-premises or dedicated DigiCert instances:
- Replace
{hostname}with your custom FQDN (for example,pki.company.internal). - All path patterns remain identical.
- The
clientauth.prefix pattern still applies for mTLS.
API troubleshooting basics
| Symptom | Likely cause | Quick fix |
|---|---|---|
| 401 Unauthorized | Missing/invalid x-api-key or expired certificate | Verify the x-api-key header; confirm the service user is active. |
| 403 Forbidden | Authenticated but lacks required role | Add the needed role in Account Manager or use a different key. |
| 429 Too Many Requests | Burst traffic | Implement backoff; spread calls across service users. |
| 503 Service Unavailable | Maintenance window | Retry after header; escalate if >10 min. |
| SSL handshake failure when using mTLS | Wrong certificate, key mismatch, or incorrect URL | Check cert/key pair and ensure URL prefix is correct. |
| Everything stopped at midnight | Key or service user reached end date | Create/rotate the key before expiry; update all integrations. |
| Works in demo, fails in prod | Using demo key against prod hostname | Generate a new key in production; update DC_BASE environment variable. |
Best practices
- Monitor Release notes for platform updates and changes.
- Always start with demo, even for simple integrations.
- Use environment variables instead of hard-coded URLs or keys whenever possible.
- Be aware of region-specific URLs.
Was this page helpful?
Provide feedback