Pitney Bowes applies rate limiting and traffic-management controls to help maintain platform stability, ensure fair use of shared resources, and protect downstream carrier and partner services.
Pitney Bowes monitors platform utilization and may adjust traffic-management controls when necessary to maintain service reliability.
If an application generates a high volume of requests within a short period, Pitney Bowes may temporarily throttle or reject additional requests to help protect platform stability.
Rate-limiting behavior may vary based on factors such as:
The Sandbox or Production environment
The API operation being invoked
Request volume and traffic patterns
Current platform conditions
Downstream carrier or partner-service constraints
Important: Pitney Bowes does not publish a single throughput value that applies to every API operation. Actual throughput and response times may vary depending on request characteristics, API dependencies, carrier response times, and overall platform conditions.
If request volume exceeds the level that can be processed reliably, Pitney Bowes may temporarily throttle or reject additional requests. The API may return:
HTTP/1.1 429 Too Many RequestsAn HTTP 429 response should be treated as a temporary condition. Applications should reduce the request rate and use an appropriate retry and backoff strategy.
Downstream carriers and partner services may also apply their own limits. As a result, some requests may be constrained by systems outside the Pitney Bowes platform.
Applications should be designed to handle temporary throttling without creating additional traffic spikes.
As a best practice:
Implement exponential backoff when retrying requests that receive an HTTP 429 response.
Avoid immediately retrying unsuccessful requests.
Add randomized delays, also known as jitter, to prevent multiple requests from retrying at the same time.
Apply retry controls across the entire integration rather than only to individual requests.
Distribute requests evenly over time where possible.
Limit concurrency and avoid large bursts of traffic.
Use batch or bulk operations where available.
Reduce the request rate.
Wait before retrying the request.
Gradually resume normal traffic after requests are being accepted successfully.
The Sandbox environment is intended for integration development and functional validation. Sandbox capacity and traffic-management settings may differ from Production.
Automated tests should avoid unnecessary repeated calls and should use mocks or test doubles where practical. Applications should not use Sandbox performance as an indication of Production throughput.
Customers with sustained high-volume workloads or specialized throughput requirements should contact Pitney Bowes Support before going live.
A limit-review request may consider:
Expected transaction volume and peak request rate
APIs and operations used by the integration
Traffic distribution and burst patterns
Concurrency and retry behavior
Downstream carrier and partner constraints
Platform capacity and operational readiness
Pitney Bowes may review the requested traffic profile and recommend an appropriate configuration or request-management approach.
Different APIs and operations may have different processing characteristics.
Traffic-management settings may be modified periodically to maintain platform reliability and service performance.
Carrier and partner systems may impose additional constraints outside the control of Pitney Bowes.
Customers should monitor API responses and adjust request patterns accordingly.
Pitney Bowes may revise traffic-management policies as platform capacity, operational requirements, and downstream-service constraints evolve.