Skip to content

Test mode

What the sandbox mirrors, how to reset it, and how to write integration tests against it.

Updated 2026-09-22

Every programme has a sandbox: a second, invisible programme that mirrors the live one. A sticky_test_… key writes there and nowhere else.

What the sandbox mirrors

Copied from liveNot copied
Earning rules, tiers, campaigns, redemption settings, expiry policy, brandingMembers, orders, ledgers, balances
The programme's currency name and valueWebhook endpoints (register test ones separately)
Plan limitsPortal links and the hosted rewards page

So an order.paid that earns 250 points in test will earn 250 in live, provided the rules have not changed since the last wipe.

Wiping it

Developers → Test mode → Wipe test data in the admin deletes every sandbox member, event, ledger entry and redemption, and re-copies the current live rules. Use it before a test run so you start from a known state — and after you change rules in live, so the sandbox matches again. It is one atomic operation; nothing partial is ever left behind.

Writing integration tests against it

  1. Keep a sticky_test_… key in your CI secrets, never a live one.
  2. Give each test run a unique customer namespace — email: "ci-<run id>-<n>@example.test" — so parallel runs never collide and you never need to wipe mid-run.
  3. Send the event, then poll GET /v1/events/{id} until status is completed rather than sleeping: processing is asynchronous.
  4. Assert on GET /v1/members/{id} balances, not on the 202 response.
  5. A test endpoint receiving webhooks from the sandbox is the only reliable way to test your handler end to end; POST /v1/webhook_endpoints/{id}/test sends a webhook.test delivery on demand.
Wait for an event
ID=$(curl -s https://stickytier.com/v1/events -H "Authorization: Bearer $TEST_KEY" \
  -H "Content-Type: application/json" -d @order.json | jq -r .data.id)
until [ "$(curl -s https://stickytier.com/v1/events/$ID -H "Authorization: Bearer $TEST_KEY" | jq -r .data.status)" = completed ]; do sleep 0.5; done

Things that behave differently in test

  • POST /v1/members/{id}/portal-links answers 409 reason: test_mode — there is no sandbox rewards page.
  • There is no sandbox rewards page, so member sign-in cannot be tested there; drive members through the API.
  • Plan limits apply in the sandbox as they do in live.
Test mode — StickyTier API