Testing safely
Keep test data separate and check how your integration handles failures.
SellApp does not expose a separate API sandbox or test-mode base URL. Every
request to https://sell.app/api reads or changes the real data of the store
selected by X-STORE.
Keep test data separate
Use a dedicated, non-public store for integration testing. Give its API key only the abilities under test, configure payment providers with their sandbox credentials where supported, and use fictional customer addresses. Never reuse a production webhook signing secret in the test store.
Keep the store slug in environment configuration so a deployment cannot switch stores accidentally:
SELLAPP_API_BASE_URL=https://sell.app/api
SELLAPP_STORE_SLUG=launch-lab
SELLAPP_API_KEY=replace-meBefore a test that changes data, check the store slug in your configuration and
make a read request. Confirm you are working in the intended store. Resources
from another store return 404, so a request cannot reveal another store's data.
Failures you can test on purpose
A useful test checks more than the happy path. These cases give your error handler a predictable response to work with:
| Case | Request | Expected result |
|---|---|---|
| Missing key | Omit Authorization from GET /v2/products | 401, code unauthenticated |
| Unknown store | Use a guaranteed-unknown X-STORE slug | 404, code resource_not_found |
| Missing ability | Use a read-only token on a documented write operation | 403, code forbidden |
| Unknown resource | Retrieve an impossible current-store resource ID | 404, code resource_not_found |
| Invalid input | Omit a required field from a write request | 422, code validation_failed, with param and errors |
| Idempotency conflict | Reuse a supported key with different input | 422, with the idempotency field named in errors |
Do not deliberately trigger the shared production rate limit in routine tests.
Unit-test your 429 handler with a recorded response instead.
Test webhooks
Use a webhook channel's test operation to send a real signed delivery. Check
that the receiver verifies the exact raw body with a constant-time signature
comparison and saves the full payload and recoverable pending work before
returning 2xx. Send a duplicate to check that it does not create duplicate
work. Saving only the event ID is not enough to recover after a crash.
Test deliveries make one attempt and report the result immediately. Normal deliveries are queued and follow the retry behavior in the webhook guide.
Clean up
Record every created ID and delete disposable catalog data where the API supports deletion. Keep invoices, orders, ledger entries, and payout records as audit history; isolate those tests with a fresh customer or store instead of trying to erase them.