Skip to main content
This page is reference material.If you are troubleshooting a theme workflow, start with the workflow pages first:Then come back here if you need the exact error shape or status-code meaning.

Error response format

All errors follow a consistent structure:

HTTP status codes


Error codes reference

Authentication errors

UNAUTHORIZED

HTTP 401. The API key is missing or invalid.
Solution: Check that your API key is correct and included in the Authorization header.

FORBIDDEN (missing scope)

HTTP 403. Your API key is valid but lacks the required scope for this endpoint.
Solution: Go to Settings → API Keys, check which scopes your key has, and add the missing one. Use GET /me/capabilities to inspect active scopes at runtime.

FORBIDDEN (shop suspended)

HTTP 403. Your shop has been suspended by Shoppex.
Solution: Reach out through the Shoppex Discord or Telegram to resolve the suspension. This is an account-level issue, not a key configuration problem.

Validation errors

VALIDATION_ERROR

HTTP 422. One or more fields failed validation.
Solution: Check the details array for specific field errors.

What each request error means

Use the status code as the first signal:
  • 422 VALIDATION_ERROR means the request shape or field values are invalid
  • 400 means the request was understood, but a business rule rejected it
  • 404 can be generic NOT_FOUND or resource-specific like PRODUCT_NOT_FOUND
For example, a wrong email format on POST /customers returns 422 VALIDATION_ERROR. An expired license on POST /licenses/validate returns 400 LICENSE_EXPIRED. A missing product on GET /products/prod_xyz returns 404 PRODUCT_NOT_FOUND.

Theme workflow troubleshooting

If you are using the theme automation flow:
  • 401 usually means your API key is missing or invalid
  • 403 usually means your key is missing themes.read or themes.write
  • 422 usually means the request body or params are wrong
  • 500 usually means the server failed while validating, previewing, publishing, or reading the theme
The most common mistake: theme.inspect fails with 403 because your key is missing themes.read, and theme.apply fails with 403 because it needs themes.write. A 422 usually means a bad request body or theme id. A 500 means something broke on the server. Check the error and retry.

Resource errors

NOT_FOUND

HTTP 404. The requested resource does not exist.
Solution: Verify the resource ID is correct.

PRODUCT_NOT_FOUND

HTTP 404. Specific product not found.

INVOICE_NOT_FOUND

HTTP 404. Specific invoice not found.

PAYMENT_NOT_FOUND

HTTP 404. Payment not found.

CUSTOMER_NOT_FOUND

HTTP 404. Customer not found.

CATEGORY_NOT_FOUND

HTTP 404. Category not found.

COUPON_NOT_FOUND

HTTP 404. Coupon not found.

SUBSCRIPTION_NOT_FOUND

HTTP 404. Subscription not found.

TICKET_NOT_FOUND

HTTP 404. Support ticket not found.

REVIEW_NOT_FOUND

HTTP 404. Review not found.

ESCROW_NOT_FOUND

HTTP 404. Escrow transaction not found.

License errors

LICENSE_NOT_FOUND

HTTP 404. License key not found.

LICENSE_INVALID

HTTP 400. License key is invalid or malformed.

LICENSE_EXPIRED

HTTP 400. License key has expired.

LICENSE_HWID_MISMATCH

HTTP 400. Hardware ID does not match the registered device.

Coupon errors

COUPON_EXPIRED

HTTP 400. Coupon has expired.

COUPON_MAX_USES_REACHED

HTTP 400. Coupon has reached maximum uses.

Idempotency errors

IDEMPOTENCY_CONFLICT

HTTP 422. The same idempotency key was used with a different request body.
Solution: Each unique request body needs its own idempotency key. If you are retrying a failed request, make sure the body matches the original. See the Idempotency section for details.

Rate limiting

RATE_LIMITED

HTTP 429. Too many requests.
Response headers:
  • X-RateLimit-Limit
  • X-RateLimit-Remaining
  • X-RateLimit-Reset
  • Retry-After when blocked
Rate limits are plan-dependent, so treat any numeric values you see elsewhere as illustrative. Check the response headers from your own requests for your current limits. Solution: Wait for Retry-After or X-RateLimit-Reset before retrying.

Handling errors in code

Every Dev API error response also returns X-Request-Id in the headers. Log that value together with error.code when you need support or want to trace a failing request.

Best practices

Log error codes

Always log the error.code for debugging. It is more reliable than parsing messages.

Handle 429s gracefully

Implement exponential backoff for rate limits. Check X-RateLimit-Reset header.

Validate before sending

Validate inputs client-side to catch errors early and reduce API calls.

Use idempotency keys

For payment creation, use idempotency keys to safely retry failed requests.