Perforce · Rate Limits

Perforce Rate Limits

Perforce products (Helix Core / P4, Helix Swarm, Helix ALM, P4 DAM, P4 Search, Helix TeamHub, Hansoft, Helix Authentication Service) are deployed as customer-managed or hosted single-tenant servers. The vendor does not publish numeric API rate limits because throughput is bounded by the customer's deployed capacity. P4 Cloud is multi-tenant managed but does not publish per-tenant API rate-limit numerics.

Perforce Rate Limits is the machine-readable rate-limit profile for Perforce on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 2 rate-limit definitions, measuring varies.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled and serviceUnavailable.

Tagged areas include Rate Limiting, Version Control, and DevOps.

2 Limits Throttle: 429
Rate LimitingVersion ControlDevOps

Limits

Self-hosted Perforce APIs server
varies
bounded by customer deployment; no vendor-published per-second / per-minute numeric
Includes Helix Core P4 REST, Swarm, Helix ALM, TeamHub, Hansoft, P4 Plan, P4 DAM, P4 Search, Helix Authentication Service. Throughput depends on hardware sizing and customer configuration.
P4 Cloud APIs tenant
varies
not publicly documented; managed-service fair-use
Multi-tenant managed Helix Core. Limits are managed by Perforce ops and not published per-key.

Policies

Customer-Managed Throughput
For self-hosted Perforce products, the deploying organization is responsible for sizing servers and any reverse-proxy / load-balancer rate limits.
Backoff
Standard practice on 429 / 503 is exponential backoff with jitter; honor Retry-After if returned by an upstream proxy.
Long-Running P4 Commands
Some Helix Core operations (sync, p4 print of large files) are long-running rather than throttled per-second; size client batch operations accordingly.
License Concurrency
Per-user license counts cap concurrent named-user sessions rather than per-second API throughput.

Sources