API Integration

Default rate limits are 1,000 requests per minute on Pro and 10,000 per minute on Enterprise. These can be increased on request with no hard ceiling for enterprise customers. Rate limit headers are included in every response so your application can manage throttling gracefully.

We use cursor-based pagination, which is more reliable than offset pagination for large datasets. Each response includes a next_cursor field when more records exist. Simply pass this cursor as a parameter in your next request. Cursors remain valid for 24 hours, so you can safely pause and resume large data pulls.

Webhook deliveries use an exponential backoff retry strategy with up to 10 retries over 24 hours. If your endpoint remains unreachable after all retries, the event is logged and you can retrieve missed events through the events API endpoint within a 7-day window.

Yes. Our API supports rich server-side filtering so you only receive the data you need. You can filter by marketplace, category, price range, date range, product attributes, and custom fields. Server-side filtering reduces bandwidth consumption and response times compared to pulling full datasets and filtering client-side.

Yes. Every account includes access to a sandbox environment populated with realistic synthetic data. The sandbox mirrors the production API exactly, so you can build and test integrations without consuming real credits or affecting live data. Sandbox credentials are separate from production credentials.

We version all APIs (currently v1) and maintain backward compatibility within major versions. Breaking changes always require a new major version. We provide a minimum of 6 months notice before deprecating any API version and keep old versions running for at least 12 months after deprecation.

A RESTful API follows the Representational State Transfer architectural style, using standard HTTP methods (GET, POST, PUT, DELETE) to perform operations on resources identified by URLs. Unlike SOAP APIs which use complex XML messaging, REST APIs are stateless, use lightweight JSON responses, and leverage existing web infrastructure. This simplicity makes REST the most widely adopted API style for web services, with easier integration and better caching characteristics.

Offset-based pagination uses page numbers and skips a set number of records (e.g., page 5 with 100 records per page skips the first 400). Cursor-based pagination uses an opaque pointer to the last record returned and fetches the next batch from that position. Cursor-based pagination is more reliable for large or frequently changing datasets because it is not affected by records being added or removed between requests, which can cause offset-based pagination to skip or duplicate records.

An idempotent API operation produces the same result regardless of how many times it is called with the same parameters. GET requests are naturally idempotent because reading data does not change it. For write operations, idempotency prevents duplicate actions when network issues cause retries — for example, ensuring a webhook subscription is created only once even if the creation request is sent twice due to a timeout. This property is critical for building reliable automated data pipelines.

An SDK (Software Development Kit) is a pre-built library in a specific programming language that wraps API calls into simple function calls, handling authentication, request formatting, error handling, retries, and pagination automatically. Instead of constructing HTTP requests manually, developers call methods like client.products.list() and receive typed response objects. SDKs reduce integration time from days to hours and prevent common implementation mistakes.

Webhook signature verification is a security mechanism where each webhook delivery includes a cryptographic signature generated using a shared secret key. The receiving server recalculates the signature from the payload and compares it to the one included in the request. If they match, the webhook is authentic. This prevents attackers from sending fake webhook payloads to your endpoints, which could trigger incorrect business actions like fraudulent price changes or fake stock alerts.

Real-time streaming pushes data to your system the instant it becomes available, using technologies like WebSockets or Server-Sent Events that maintain persistent connections. Polling requires your system to repeatedly check for updates at fixed intervals, which introduces latency equal to your polling interval and wastes resources on empty checks. Streaming is ideal for time-critical applications like price monitoring, while polling suits batch analytics where immediate delivery is not required.