To maintain platform stability and ensure fair usage across all clients, PCE APIs enforce a rate limiting mechanism. This helps protect the system from excessive traffic while ensuring consistent performance for all integrations.

Rate Limit Policy

Our APIs currently support the following rate limit:

What Happens When You Exceed the Limit?

If your application exceeds the defined rate limit:

• The API will return 429: Too Many Requests response
• Additional requests within the time window will be rejected (dropped)
• Normal processing resumes automatically once the rate window resets

Best Practices

To ensure a smooth integration experience and avoid throttling:

• Implement retry logic with exponential backoff
• Avoid burst traffic by distributing requests evenly
• Cache responses where applicable to reduce redundant API calls
• Monitor API usage to stay within thresholds

Recommended Handling Strategy

When receiving 429 response:

• Pause further requests temporarily
• Retry the request after a short delay
• Gradually increase retry intervals if limits continue to be hit

sequenceDiagram
    participant App as Your App
    participant PCE as PCE API

    loop Normal traffic
        App->>PCE: API Request
        PCE-->>App: 200 OK
    end
    Note over App,PCE: Rate limit exceeded (>1000 req / 10s)
    App->>PCE: API Request
    PCE-->>App: 429 Too Many Requests
    App->>App: Pause + exponential backoff
    App->>PCE: Retry after delay
    PCE-->>App: 200 OK (rate window reset)

Common Integration Scenarios

Scenario 1: Batch processing payouts without hitting rate limits

A payroll platform processes 5,000 employee payouts every Friday. To stay within the 1,000 requests per 10 seconds limit, the platform distributes requests across time windows rather than sending them all at once.

Approach:

1. Split the 5,000 payout requests into batches of 800 (leaving headroom below the 1,000 limit).
2. Send each batch over a 10-second window.
3. Wait for the window to reset before sending the next batch.
4. Total processing time: approximately 70 seconds for all 5,000 payouts.
5. If any request returns 429, pause for 2 seconds, then retry with exponential backoff.

Scenario 2: Handling rate limits during high-volume webhook processing

A marketplace platform receives a surge of webhook notifications during end-of-day settlement. The platform calls GET APIs to retrieve transaction details for each webhook, which can spike request volume.

Approach:

1. Queue incoming webhook events instead of processing them synchronously.
2. Process the queue at a controlled rate (e.g., 500 requests per 10 seconds) to stay within limits.
3. Cache transaction details locally to avoid redundant GET calls for the same transaction.
4. If a 429 response is received, re-queue the request and retry after a short delay.

Scenario 3: Exponential backoff for automated reconciliation

A treasury operations team runs an automated reconciliation job that polls transaction statuses every 5 minutes. During peak processing windows, the polling volume may approach rate limits.

Approach:

1. First retry after 429: wait 1 second.
2. Second retry: wait 2 seconds.
3. Third retry: wait 4 seconds.
4. Cap maximum retry delay at 30 seconds.
5. Log all 429 responses for monitoring and capacity planning.