---
title: "Rate limiting"
description: "Understand how rate limiting works for the Trust Lifecycle Manager API.\n"
source_url: https://dev.digicert.com/trust-lifecycle-api/concept-rate-limiting.html
---

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](https://dev.digicert.com/md/get-started/error-handling-rate-limits.md) 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 group | Details |
|-----------|---------|
| Public APIs | All 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 APIs | The 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 group | Requests per minute | Limit applied per |
|-----------|---------------------|-------------------|
| Public APIs | 5,000 | Customer account |
| SCEP | 1,000 | Enrollment profile |
| EST | 500 | Enrollment profile |
| CMP | 500 | Enrollment 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](https://dev.digicert.com/md/trust-lifecycle-api/api-reference.md) 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.

<!-- Editorial TODO: Before finalizing this section, ask Kashyap Sharma to confirm the exact affected paths and methods for each API group, including whether EST/SCEP/CMP limits cover only issuance or also renewal and other protocol operations. The Jira ticket and Confluence source describe API groups but do not enumerate endpoints or establish issuance-only scope. -->

## 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](https://dev.digicert.com/md/get-started/error-handling-rate-limits.md) 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](https://dev.digicert.com/md/trust-lifecycle-api/tutorials/bulk-certificate-revocation.md).   
**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 <a href="https://www.digicert.com/contact-us/" target="_blank" rel="nofollow noopener noreferrer">Contact DigiCert</a>.

## Related topics

- [DigiCert API error reference](https://dev.digicert.com/md/get-started/error-handling-rate-limits.md): General HTTP error handling.
- [Trust Lifecycle Manager API reference](https://dev.digicert.com/md/trust-lifecycle-api/api-reference.md): Operations and documented responses.
- [Bulk revoke multiple certificates](https://dev.digicert.com/md/trust-lifecycle-api/tutorials/bulk-certificate-revocation.md): A tutorial whose workload can generate many requests.
- [Request a TLS certificate](https://dev.digicert.com/md/trust-lifecycle-api/tutorials/request-a-tls-certificate.md): A tutorial for issuing a certificate.