Errors and limits

Every error answers { "code": <HTTP status>, "message": "…", "rcode": "…" }. Branch on rcode (stable) and show message to people. Some errors have no rcode; use the HTTP status for those.

The connector returns the backend's message and rcode inside the tool result, marked as an error. A permission the connection lacks is refused by the connector itself before any call, with a message naming the permission.

Error codes#

On creating a promotion, an unknown SKU or a code the shop already uses is a 400 whose message says which.

Key management in the dashboard#

Row errors#

Write calls answer 200 with one result per row, in the order sent, and a summary with the count per status plus total. A bad row never stops the others. A row with status error carries an error message. Report every one to the owner.

Common row errors:

• an unknown category;
• a SKU that exists only on a marketplace, not on the SellerSideKick store;
• stock or parent_sku sent for an existing product;
• a new product missing name, price, category or brand;
• a parent_sku that is a variant, a marketplace-only product or doesn't exist;
• the same SKU twice in one request;
• stock: expected_from no longer matches on hand, or a delta would go below what open orders hold, or a delta on a SKU that was never counted.

Limits#

Retrying#

• 429: wait the number of seconds in the Retry-After header, then resend the same request.
• Product updates (POST /products/upsert): safe to resend; rows already applied come back unchanged.
• Stock (POST /stock): safe to resend with the same idempotency_key; applied rows come back already_applied. Use a new key for each new change.
• Promotion create: not safe. List promotions first to see whether it was created.
• Promotion update and status: safe to resend.
• 401 and 403: don't retry; tell the owner what the message says.