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:

Calls with side effects

EndpointWhat happensHow to test it safely
Create order, Update order, Create order fulfillment, Update order fulfillment, Send aggregated order infoAdds 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 collectionAdds 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 customerCreates 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 answersChanges which reviews, comments and vote counts shoppers see.Use test reviews and answers only.
Adjust Loyalty Customer Points, Record Loyalty Customer ActionChanges 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 subscriptionPermanently 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.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, 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 200 with 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 401 and retries once. App partners: you store one token per store, and after 3 401 invalid_token responses in a row you show the integration as disconnected and let the merchant reinstall.
  • Your code waits on 429 (using Retry-After), 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, your endpoint answers quickly with 200 and 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.

Did this page help you?