Zum Hauptinhalt springen
Omneya
EN
Start test system Try it
Developer docs menu

Go-live checklist

The checks to run before your app sends real orders to an Omneya shop, from the live key to error handling.

Access and configuration

  1. You have the shop’s address and a live key (omn_live_). Each shop has its own address, for example https://shop.example.com/api/v1.
  2. The operator has set up the access with the scope orders.write, the shop and the default referrer. Add orders.read if your app reads orders back, and customers.read or customers.write if it uses the customer endpoints.
  3. You have agreed with the operator whether Match existing customers by email is enabled, and your app sends email_verified: true only for confirmed addresses. See How customers are matched.
  4. The key is stored in a secret store or environment variable, not in source code, logs or request bodies.

Connection

  1. GET /ping answers 200, client.environment is live, and client.scopes contains orders.write.
  2. GET /payment-methods and GET /referrers were called with the live key (and GET /order-statuses if you send order_status_id), and your app uses only these IDs; any other payment method is rejected with payment_method_not_available. IDs from a test shop may differ.

If the operator has set up an AI assistant connection for you, you can use it to check a test order and your recent requests. Your app itself uses only the live key.

Orders

  1. A test order answers 201, and your app stores the returned id with its own order.
  2. Sending the same order again answers 200 with "duplicate": true, and your app does not treat it as an error.
  3. An order with a deliberate mistake, for example an unknown sku, answers 422 with a field code in error.details, and your app shows or logs the code.
  4. Your app reads warnings and alerts someone on no_shipping_method, customer_already_linked and collective_invoice_single_order.
  5. Your app takes the order total from grand_total_gross, not from its own calculation.
  6. Test orders have been checked with the operator and cancelled if needed.

Error handling

  1. Timeouts, 429 and 5xx are retried with unchanged data and increasing wait times, and Retry-After is respected. See Retries and duplicate protection.
  2. 422, 409, 401, 403 are not retried unchanged.
  3. Your app logs error.code, error.details and, for 500, error.details.reference.
  4. A 503 without the error envelope during maintenance does not crash your error handling. See Errors.
  5. Orders that could not be sent are kept and sent later, so none are lost while the shop is unreachable.

Volume

  1. Your expected peak stays below the key’s limit, 120 requests per minute by default. If not, ask the operator for a higher limit. See Rate limits.

Support

  1. You know how to reach the operator, and your support process collects time, path, external_order_id and error.details.reference for a failed request. The operator can look these requests up for 14 days. See Request log.