Testing your integration
How to test against Yotpo without touching real shoppers, which calls have side effects, and a checklist before you go live.
The Yotpo APIs have 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 store
- Merchants and agencies: 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).
- App partners: build and test against the Yotpo test account you opened when you registered your app. Install your app on it through the normal install flow, so you test the same OAuth steps a merchant goes through. Never test against a merchant's live store without their agreement.
Don't test against a 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.
- Some calls change what shoppers see, such as publishing reviews or adjusting loyalty points.
- Test traffic uses the same rate limit as live integrations.
Keep store IDs, secrets and access tokens in configuration or a secrets store, not in code, so you can switch from the test store to the live one without changing code.
Calls that are safe to repeat
These only read data:
- All
GETrequests, for example Retrieve orders, Retrieve products and Retrieve customers. - Generate access token. Each call returns a token; it doesn't change the store.
- All storefront endpoints on
api-cdn.yotpo.com, including the review search endpoints that usePOST. - Best Reviews and Best Sentences, which use
POSTto pass filters but only read. - Product Potential Points, which uses
POSTbut only calculates.
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 or changes the order. 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. |
| Publish/Unpublish Reviews, Create New Comment, Update Existing Comment, Delete Comment, Vote on answers | Changes which reviews, comments and vote counts shoppers see. | Use test reviews and answers only. |
| Adjust Loyalty Customer Points, Record Loyalty Customer Action | Changes the customer's points balance and history. The resulting loyalty events can reach the merchant's other tools, such as email or SMS flows. | Use test customers with example.com addresses, and small amounts. |
| Create subscription (and the app partners store subscription) | An active subscription sends the store's real events, including shopper data, to the target URL. A target that a subscription uses can't be deleted until you delete or update that subscription. | 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. |
| Remove Application (app partners) | Deletes the app's access token. The merchant has to install your app again before you can call their store. | Use it on your test account to test your uninstall flow, then reinstall. |
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.comemail 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_idthat starts withtest-, so you can find them later with theexternal_idsfilter. - Keep a list of everything you create (products, orders, customers, comments, point adjustments, 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). - Storefront endpoints return
200with no reviews for an unknown product ID (see Errors), so a typo looks like "no reviews yet". Use product IDs that exist in the test store.
Rate limits apply during tests
Test traffic counts against the same limits as live traffic: 5 requests per second per store on api.yotpo.com. 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, app secret and access tokens are used only on your server and never reach the browser.
- Your code requests a new store token after a
401and retries once. App partners: you store one token per store, and after 3401 invalid_tokenresponses in a row you show the integration as disconnected and let the merchant reinstall. - Your code waits on
429(usingRetry-After), retries reads on5xx, and treats a409on a retried create as success. - The live store ID and API secret come from configuration.
- Product, order and customer
external_idvalues 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, your endpoint answers quickly with
200and ignores duplicate deliveries (see About webhooks), and test subscriptions are deleted. - App partners: merchants can uninstall from your product (Remove Application) and from Yotpo (the App Disconnected event). Then certify and launch your integration.
Updated 12 days ago
