Performance, Reliability & Rate Limiting

API Response Times

Nuitee Connect continuously monitors API performance across all major endpoints.

Under normal operating conditions:

Average response time for rate search and prebooking requests is below 3 seconds
Response times may vary depending on:
- Requested destination and inventory size
- Upstream supplier response times
- Request complexity and filters

Nuitee Connect is designed to optimize latency while maintaining data accuracy and availability.

Reliability and Error Rates

Nuitee Connect tracks API reliability and error ratios across production environments.

Typical metrics include:

5xx error ratio below 0.05%
Automatic detection and alerting for abnormal error spikes
Rapid investigation and mitigation of upstream or infrastructure-related issues

Client-side errors (4xx) are excluded from service error ratio calculations.

Rate Limiting

To ensure platform stability and fair usage, Nuitee Connect enforces rate limits on API requests.

Default Limits

Default numeric rate limits (Sandbox and Production), scope (per API key), and the 429 response body are published only on the Rate Limiting reference page. Always use that page as the single source of truth — do not use older “500 RPS per customer” wording from prior revisions of this guide.

Reference: Rate Limiting (sandbox 5 RPS, production 250 RPS, per API key)

When the rate limit is exceeded:

Requests are rejected with HTTP 429 Too Many Requests.
Parse the 429 body and any Retry-After header from the reference page above.

Recommended client backoff strategy

Clients should implement retries with exponential backoff and jitter for transient 429 responses. A conservative, commonly used pattern is:

Initial base delay: 500 ms
Backoff factor: 2.0
Max retries: 6
Cap maximum delay (for example, 30 seconds)
Honor Retry-After header when present (use that value before applying backoff)

Example (pseudocode):

retry = 0
base = 0.5 # seconds
maxRetries = 6
while retry < maxRetries:
if server_returns_retry_after:
sleep(server_retry_after)
else:
wait = random_between(0, base (2 * retry))
sleep(min(wait, 30))
response = attempt_request()
if response.success:
break
if response.status != 429:
handle_non_retryable_error(response)
retry += 1

This pattern reduces synchronized retry storms (thundering herd) and helps maintain platform stability while attempting to recover from transient throttling.

Higher Rate Limits

Higher rate limits may be granted based on:

Use case requirements
Traffic patterns
Infrastructure capacity planning

Customers requiring higher throughput should contact Nuitee Connect support to discuss custom limits.

Throttling Behavior

Rate limiting and throttling mechanisms are designed to:

Protect platform stability
Prevent abusive or accidental traffic spikes
Ensure consistent performance for all customers

Throttling is applied automatically and transparently when limits are exceeded.

Monitoring & Observability for Customers

Nuitee Connect provides customers with visibility into their API usage and performance through the Nuitee Connect Dashboard.

Available metrics include:

API response times
Request volume and rate
Error rates (4xx / 5xx)
Rate limiting events
Historical usage and performance logs

This allows customers to:

Monitor real-time performance
Investigate historical issues
Optimize integrations and traffic patterns

Customer Responsibilities

Customers are responsible for:

Implementing retries with exponential backoff for transient errors
Handling HTTP 429 responses appropriately
Monitoring their own API usage and performance metrics
Designing integrations that tolerate occasional upstream delays

Continuous Optimization

Nuitee Connect continuously evaluates performance and reliability metrics to:

Improve response times
Reduce error rates
Scale infrastructure in line with customer demand