Rate limiting

Understand how rate limiting works for the Trust Lifecycle Manager API.

  5 minute read  

Rate limiting protects the stability, performance, and availability of the DigiCert® Trust Lifecycle Manager APIs. It controls the number of requests a client can make within a defined period.

Without rate limiting, a single client generating excessive requests, a misconfigured integration, or repeated retries can consume shared capacity and negatively affect other customers. Rate limiting helps mitigate these risks by enforcing configurable request limits at the platform level.

How rate limiting helps

  • Fair resource usage: Prevents a single account or profile from consuming a disproportionate share of available resources.
  • Improved platform stability: Rejects requests that exceed configured limits before they reach the application services and downstream databases.
  • Predictable performance: Helps manage traffic spikes and maintain consistent service availability under varying request loads.
  • Configurable limits: Supports request limits tailored to observed traffic patterns and platform capacity.

This guide explains which Trust Lifecycle Manager requests are limited, how the limit is scoped, what your client receives when it hits a limit, and how to build clients that handle it gracefully.

Before you begin

This guide assumes you understand:

HTTP status codes, in particular how a client should treat 429 and 5xx responses. See the DigiCert API error reference for general HTTP error handling.
Which Trust Lifecycle Manager interfaces your integration uses, such as the REST API, the enrollment protocols (EST, SCEP, and CMP), or both.

API groups and rate-limit scope

Rate limiting in Trust Lifecycle Manager depends on what kind of request you send. Each kind is counted against a different identifier.

API groupDetails
Public APIsAll requests that your account sends to these APIs count against that account’s allowance, so a busy integration can affect other users of the same account.
EST, SCEP, and CMP APIsThe limit applies per enrollment profile. All clients that enroll through the same profile share that profile’s allowance. Each enrollment profile supports only one protocol, either EST, SCEP, or CMP.

API rate limits

The following limits apply to Trust Lifecycle Manager API requests.

API groupRequests per minuteLimit applied per
Public APIs5,000Customer account
SCEP1,000Enrollment profile
EST500Enrollment profile
CMP500Enrollment profile

Affected endpoints

Public API requests count against the customer account’s allowance. For example, POST /mpki/api/v1/certificate issues a certificate through the REST API using a profile configured for REST API enrollment. See the Trust Lifecycle Manager API reference for operation details.

Requests through the EST, SCEP, and CMP APIs count against the enrollment profile’s allowance. The protocol used for a request determines which API group it belongs to; certificate issuance through the REST API is distinct from enrollment through EST, SCEP, or CMP.

How it works

Each request is checked against the limit that matches its type, such as the customer account for Public APIs, or the enrollment profile for EST, SCEP, and CMP. A request within the limit is processed unchanged. A request over the limit is rejected with HTTP 429, and it isn’t processed.

What your client receives

When a limit is exceeded, the API returns HTTP 429 Too Many Requests. See the DigiCert API error reference for general HTTP error handling.

What happens within the limit

When your API requests are within the rate limit, they reach Trust Lifecycle Manager as usual. Rate limiting does not change your requests or the responses you receive.

Common rate-limiting scenarios

Pattern 1: Bulk operations from an integration

When to use: Your integration performs many operations in a short time, such as the work in Bulk revoke multiple certificates.
How it works: The requests all count against your account’s allowance. Spread the work over time instead of sending it as one burst, and treat a 429 as a signal to slow down rather than as a failure.

Pattern 2: Many devices enrolling through one profile

When to use: A fleet of devices enrolls or renews through the same EST, SCEP, or CMP enrollment profile. How it works: The devices share the profile’s allowance. Stagger enrollment and renewal times, and have each client retry with backoff when it receives a 429, so that a large fleet doesn’t retry in lockstep.

Pattern 3: Retrying after a 429

When to use: Any client that calls Trust Lifecycle Manager.
How it works: On a 429, wait before retrying. Implement exponential backoff in your client, increasing the delay after each unsuccessful attempt and stopping after a bounded number of retries.

Best practices

  • Use exponential backoff for 429 responses: Increase the delay between retries to avoid repeatedly exceeding the rate limit.
  • Add random delays to retries: Introduce a small random delay (jitter) to prevent multiple clients from retrying simultaneously.
  • Limit retry attempts: Set a maximum number of retries to prevent repeated requests when the rate limit continues to apply.
  • Distribute bulk requests: Spread large batches of API requests over time to avoid sudden traffic spikes.
  • Avoid unnecessary API calls: Cache reusable responses where appropriate and avoid excessive polling.
  • Monitor 429 responses: Log rate-limit errors and review recurring occurrences to identify and adjust excessive API usage.

Request a higher limit

If your integration needs more capacity, contact DigiCert Support to request a higher limit for your account or enrollment profile. You can reach DigiCert through Contact DigiCert.