Rate limits

Rate limits restrict the number of requests or actions allowed within a certain timeframe to prevent overuse or abuse. Port enforces multiple rate limits to control extensive usage of Port's API.

Port's rate limits vary by route family to protect platform stability and prevent abusive concurrent workloads.
Rate limits are enforced at the Organization level.

When usage exceeds acceptable thresholds, requests may take longer to be processed or fail with 429.

Rate limits table

The Burst value is the number of extra requests you can send immediately above the steady rate limit before throttling starts. Use burst to absorb short traffic spikes, while the full rate limit still applies across the 5-minute window. When multiple route rules can match the same request, the highest-priority gateway rule is applied.

Description	Rate limit	Burst	Enforcement date
Unauthenticated requests	100 requests per 5 minutes	10	Already enforced
Entities API requests	35,000 requests per 5 minutes	3,500	Already enforced
Blueprints API requests	15,000 requests per 5 minutes	1,500	May 21st, 2026
Entities search requests	35,000 requests per 5 minutes	3,500	May 21st, 2026
Single entity upsert requests	10,000 requests per 5 minutes	200	May 21st, 2026
Entities bulk upsert requests	35,000 requests per 5 minutes	3,500	May 21st, 2026
All other API requests	15,000 requests per 5 minutes	1,500	Already enforced

Port's API rate limits are subject to change as new features are added, functionality is changed or in order to protect system health. The most up to date rate limit information will always be available in the headers returned in API responses.

Monitor rate limit headers

Each API response includes headers that provide information about your current rate limit status:

Header name	Description
x-ratelimit-period	The period of time the rate is calculated
x-ratelimit-limit	The limit of the rate the user can achieve
x-ratelimit-remaining	The number of requests to send during the period before the user is limited
x-ratelimit-reset	The number of seconds before the rate limit is reset
To avoid hitting rate limits, you should monitor the rate limit headers in your API responses.

The x-ratelimit-remaining header shows how many requests you have left in the current window. When this number gets low, you should reduce your request frequency or implement a backoff strategy.

The x-ratelimit-reset header tells you when the rate limit window will reset, which can help you plan when to resume normal request rates.

Rate limit enforcement levels

Rate limits are enforced at the organization level by default. Service account users are an exception and are rate-limited at the user level.

Understanding rate limit categories

Different API operations count toward different rate limit buckets. Understanding which bucket applies to your workload helps you plan capacity.

Entities API requests

This category includes all entity-related operations:

• GET /v1/blueprints/{id}/entities - List entities.
• GET /v1/blueprints/{id}/entities/{entity_id} - Get single entity.
• PATCH /v1/blueprints/{id}/entities/{entity_id} - Update entity.
• DELETE /v1/blueprints/{id}/entities/{entity_id} - Delete entity.
• POST /v1/blueprints/{id}/bulk/entities/delete - Delete multiple entities.
• DELETE /v1/blueprints/{id}/all-entities - Delete all entities of blueprint.

Single entity upsert requests

This category applies specifically to:

• POST /v1/blueprints/{id}/entities - Create single entity.
• PATCH /v1/blueprints/{id}/entities/{entity_id} with upsert behavior.

Entities bulk upsert requests

This category applies to:

• POST /v1/blueprints/{id}/entities/bulk - Bulk create/upsert entities.

Entities search requests

This category applies to:

• POST /v1/entities/search - Search across all entities.
• GET /v1/blueprints/{id}/entities with query parameters.

Blueprints API requests

This category includes all blueprint-related operations:

• GET /v1/blueprints - List blueprints.
• GET /v1/blueprints/{id} - Get single blueprint.
• POST /v1/blueprints - Create blueprint.
• PATCH /v1/blueprints/{id} - Update blueprint.
• DELETE /v1/blueprints/{id} - Delete blueprint.

For guidance on avoiding rate limits, tracking your usage, and handling 429 responses, see Rate limit best practices.