# Traffic Shaping

## Overview

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.

## How Rate Limiting Works

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.


## When Rate Limiting Occurs

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
HTTP/1.1 429 Too Many Requests
```

An 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.

## Handle Rate Limits Gracefully

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.


### Recommended response to an HTTP 429 error

1. Reduce the request rate.
2. Wait before retrying the request.
3. Gradually resume normal traffic after requests are being accepted successfully.


## Sandbox Considerations

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.

## Requesting a Limit Review

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.

## Additional Notes

- 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.*