Skip to main content
This endpoint is for connected custom stores. Authenticate with that store’s Orders API key, not your platform API key, browser pixel code, or OAuth token. Keep the key in a server secret manager. Rotating it invalidates the old key; update your server configuration immediately after rotation. Only call after verifying payment or a refund with your order system. Do not trust a browser’s claimed payment status or amount. There is no dry-run parameter: a test order can affect commissions unless isolated or marked isSample: true. Download the OpenAPI specification for client generation. It uses the same store-scoped authentication described here.

Submit or update a verified order

Despite their names, the *Cents fields always use the currency’s minor unit: USD 65.00 is 6500; JPY 65 is 65; KWD 65.000 is 65000. Send integers. Pixel display values use major units and are not the source of payable money. The original total, currency, payment time, and existing visitor/checkout identity cannot change for the same order ID. Send cumulative refund amounts when an order is refunded. Do not send a new order ID for a refund.

Refunds and commission

The store’s Deduct refunds setting controls whether refunds reduce commission. When deductions apply, a percentage commission uses the remaining order value. A fixed commission is reduced in proportion to the refund: a 25% refund reduces a 4commissionby4 commission by 1. A full refund reverses the full commission. A cancellation does not earn commission. Find this setting in the store’s Tracking tab. Changes apply to new commission calculations. Previously calculated commissions keep their refund rules. If commission has already been paid, the reversal becomes an adjustment to a later payout. An order involved in a payout in progress is retried after that payout settles. The order keeps its original commission terms and exchange-rate snapshot so a replay does not change its calculation.

Node.js example

Responses and retries

A successful response is HTTP 200:
Replaying or updating an existing order returns HTTP 200 with duplicate: true. This means the order already existed, not that an incoming refund was ignored. It does not create another order. A changed total or currency for an existing ID returns HTTP 409. A valid cumulative refund updates the existing order. Acceptance confirms storage. It does not guarantee attribution or payout. A qualifying creator click, eligible commission terms, and verified order data are also required.

Request limits

refundedCents must not exceed totalCents; status: "refunded" requires the full original total as refundedCents. Refund amounts are cumulative and never decrease. Cancellation and sample status cannot be undone by replaying an older paid payload. Keep your authoritative order state in sync before retrying.

Refund example

Send the same original purchase identity and payment timestamp, updating cumulative refunds:
Retry network failures, 429, and transient 5xx responses with exponential backoff and jitter in a durable server queue. Keep the same order ID, original purchase fields, and current cumulative refund state. Inspect other 4xx errors instead of retrying indefinitely. Error bodies expose an error message. The response’s orderId is SideShift’s internal order ID. It can be null when a privacy-redacted order is suppressed; acceptance does not recreate deleted data. HTTP 200 does not confirm a matching creator click, commission payment, or delivery to an advertising network.