What are the best practices for using a mockup API?

Key practices include: batch requests when possible, cache responses, use webhooks instead of polling, handle errors gracefully, validate inputs before API calls, and optimize image sizes for your use case.

How should I handle API rate limits?

Implement exponential backoff on rate limit errors, queue requests during high-volume periods, distribute processing across time windows, and consider upgrading your plan if consistently hitting limits.

What's the best way to structure mockup API requests?

Group related operations into single requests where possible, use consistent naming for Smart Object targets, include all required parameters upfront, and specify output format/quality to avoid unnecessary re-processing.

How do I optimize mockup API performance?

Pre-process and cache templates, use CDN URLs for input images, request appropriate output dimensions (not larger than needed), enable compression for transfers, and parallelize independent render requests.

What error handling should I implement for mockup APIs?

Handle network timeouts, validate API responses, retry transient errors with backoff, log failures for debugging, implement fallbacks for critical paths, and alert on repeated failures. Never assume success.

API Integration Best Practices

Building robust API integrations means handling limits and errors gracefully. This guide covers best practices for parallel processing, retry logic, and error handling - so your mockup pipeline never breaks.

Understanding Parallel Limits

SudoMock uses parallel limits to ensure fair usage and consistent performance. These limits determine how many simultaneous requests you can have in-flight at once:

Response Headers

Every API response includes parallel limit headers:

x-concurrent-limit - Your parallel limit
x-concurrent-remaining - Available slots
Retry-After - Seconds to wait (only on 429 responses)

Handling 429 Errors

When you exceed parallel limits, the API returns 429 Parallel Limit Reached. Here's how to handle it properly:

Basic retry with backoff

javascript

Exponential Backoff

For retry logic, exponential backoff prevents overwhelming the API. The delay doubles with each retry attempt:

Retry 1

First attempt

Retry 2

Second attempt

Retry 3

Third attempt

Retry 4

Fourth attempt

Exponential backoff with jitter

javascript

Why Jitter?

When multiple clients hit limits simultaneously, they all retry at the same time - causing another limit breach. Adding random jitter spreads out retries.

Parallel Processing Strategy

For high-volume workloads, process requests in parallel up to your plan's limit:

Parallel worker pool

javascript

Error Types & Handling

Don't Retry Everything

Only retry 429 and 5xx errors. Client errors like 400 and 401 won't succeed on retry - fix the underlying issue instead.

Monitoring & Metrics

Track these metrics to optimize your API usage:

Best Practice

Use the x-concurrent-remaining header proactively. If it's getting low, wait for active requests to complete before sending more.

Related Resources

Render API Reference

Complete endpoint documentation

View Plans

Compare parallel limits by tier

Scaling Guide

High-volume best practices

Status Page

Check API health

Understanding Parallel Limits

SudoMock uses parallel limits to ensure fair usage and consistent performance. These limits determine how many simultaneous requests you can have in-flight at once:

Response Headers

Every API response includes parallel limit headers:

x-concurrent-limit - Your parallel limit
x-concurrent-remaining - Available slots
Retry-After - Seconds to wait (only on 429 responses)

Handling 429 Errors

When you exceed parallel limits, the API returns 429 Parallel Limit Reached. Here's how to handle it properly:

Basic retry with backoff

javascript

Exponential Backoff

For retry logic, exponential backoff prevents overwhelming the API. The delay doubles with each retry attempt:

Retry 1

First attempt

Retry 2

Second attempt

Retry 3

Third attempt

Retry 4

Fourth attempt

Exponential backoff with jitter

javascript

Why Jitter?

When multiple clients hit limits simultaneously, they all retry at the same time - causing another limit breach. Adding random jitter spreads out retries.

Parallel Processing Strategy

For high-volume workloads, process requests in parallel up to your plan's limit:

Parallel worker pool

javascript

Error Types & Handling

Don't Retry Everything

Only retry 429 and 5xx errors. Client errors like 400 and 401 won't succeed on retry - fix the underlying issue instead.

Monitoring & Metrics

Track these metrics to optimize your API usage:

Best Practice

Use the x-concurrent-remaining header proactively. If it's getting low, wait for active requests to complete before sending more.