Testing your integration - Yotpo Core API

The Core API has no sandbox or test mode. Every request reaches a real Yotpo store, including requests sent from Try It on the reference pages, which use whatever store ID and token you enter.

Use a separate test store

Test against a Yotpo store you keep only for testing, with its own store ID and API secret. To get one, ask your Yotpo contact (your account manager or Yotpo support) for a separate store to test with.

Don't test against your live store:

Orders and fulfillments can trigger review request emails to the email address on the order.
Products, orders and customers can't be deleted through the API, so test data stays in the store.
Test traffic uses the same rate limit as your live integrations (5 requests per second per store).

Keep the store ID and API secret in configuration, not in code, so you can switch from the test store to the live store without changing code.

Calls that are safe to repeat

These only read data:

All GET requests, for example Retrieve orders, Retrieve products and Retrieve customers.
Generate access token. Each call returns a token; it doesn't change the store.

Calls with side effects

Endpoint	What happens	How to test it safely
Create order, Update order, Create order fulfillment, Update order fulfillment, Send aggregated order info	Adds the order to the store. Once it has a fulfillment with `status: success`, Yotpo can send a review request email to the order's customer. Orders can't be deleted.	Use `example.com` email addresses only. To keep a test order out of review requests, set `custom_properties.suppress_review_request` to `true`.
Create product, Create product variant, Create collection	Adds catalog entries. They can't be deleted through the API. Send aggregated order info also creates products that don't exist yet.	Use clearly named test products in the test store. To retire one, update it with `is_discontinued: true`.
Create or update customer	Creates or updates a customer profile. Customers can't be deleted through the API.	Use `example.com` email addresses and `external_id` values you can recognize.
Create subscription	An active subscription sends the store's real events, including shopper data, to the target URL.	Point targets only at endpoints you control. Create subscriptions with `active: false` until your endpoint is ready, and delete test subscriptions, filters and targets afterwards.
Delete target, Delete filter, Delete subscription	Permanently removes the webhook object.	Delete only objects you created for the test.

V1 calls have the same effects: Create order and Create mass orders add orders that can trigger review requests, and Create or update mass products emails a report to return_email_address.

Test data rules

Use example.com email addresses. The domain is reserved, so mail sent there is never delivered. When you need to receive an email, use an inbox you own. Never use real customers' names, emails or phone numbers.
Give test objects recognizable IDs, for example an external_id that starts with test-, so you can find them later with the external_ids filter.
Keep a list of everything you create (products, orders, customers, webhook objects) so you can clean up what can be cleaned up.
Create products before orders: an order whose line items refer to an unknown product returns 404 (see Errors).

Rate limits apply during tests

Test traffic counts against the store's limit of 5 requests per second, the same as live traffic. Run load tests against the test store, never the live one, and handle 429 responses as described in Errors.

Before you go live

Your API secret and access tokens are used only on your server and never reach the browser.
Your code requests a new token after a 401 and retries once.
Your code waits on 429 (using Retry-After) and retries reads on 5xx, and treats a 409 on a retried create as success.
The live store ID and API secret come from configuration.
Product, order and customer external_id values match the IDs your platform uses.
Orders send real customer emails only in the live store, and test orders never reach it.
Webhook targets point at your production endpoint, and test subscriptions are deleted.