Environments
Sandbox vs. production — hosts, credentials, IP whitelisting, and data isolation
Environments
Starship runs two fully-isolated environments. Your sandbox wallet, orders, products, and credentials are separate from production — nothing leaks between them. This separation is the feature, not a bug: it lets you pound the sandbox without risk.
Hosts
| Environment | API host | Admin console | Purpose |
|---|---|---|---|
| Sandbox | https://api-playground.starshiprewards.com | https://admin-playground.starshiprewards.com | Integration development, load testing, manual QA |
| Production | https://api.starshiprewards.com | https://admin.starshiprewards.com | Real money, real vouchers, real end-users |
Use the sandbox for everything up to and including the last dress rehearsal before launch. Production is not a test environment.
Credentials per environment
Your sandbox and production credentials are different keys, different secrets, different signing secrets. You'll know which is which by prefix:
| Prefix | Environment |
|---|---|
sk_test_… | Sandbox |
sk_live_… | Production |
Never share or commit either. If a sandbox key leaks, rotate it (low risk but still worth doing); if a prod key leaks, rotate immediately and audit wallet transactions for unauthorized orders.
Env var hygiene. A common production incident is "sandbox key shipped to prod by mistake" or vice versa. Enforce this via deploy-time config validation: assert that your prod deploy only sees a sk_live_ key, and your staging deploy only sees sk_test_. Fail the deploy loudly if they don't match.
IP whitelisting
Starship whitelists your egress IPs — the public IPs your backend requests originate from. If your request arrives from an un-whitelisted IP, the API returns 401 E_UNAUTHORIZED_ACCESS regardless of whether your credentials are valid.
What you need to send
For each environment, email your Starship contact:
- A list of egress IP addresses or CIDR blocks (e.g.,
34.120.45.67/32,52.208.0.0/13) - Which environment each applies to (sandbox, production, or both)
- A human-readable description (e.g., "AWS NAT Gateway, ap-south-1, primary")
Typical sources
| Your infra | How to find the egress IP |
|---|---|
| AWS + NAT Gateway | EIP attached to the NAT gateway in each AZ |
| GCP + Cloud NAT | External IPs listed in your VPC's Cloud NAT config |
| Vercel / Fly / Render | Provider's documentation — usually a static IP per region |
| Kubernetes + dedicated egress | Egress controller's external LB IP |
| Traditional VM on a fixed public IP | The VM's public IP |
Propagation time
Whitelist changes take 24–48 hours to propagate. Request them well before your launch window; do not assume you can add an IP on deploy day.
Data isolation guarantees
| What's separated | Sandbox behavior |
|---|---|
| Products catalog | Sandbox may have fewer products, or stub products; your account manager can seed specific brands on request |
| Inventory | Sandbox inventory is replenished on a permissive schedule so INSTANT fulfillment is easy to exercise |
| Wallet balances | Sandbox wallets can be topped up on request (up to reasonable test limits) for free |
| Orders | Sandbox orders generate real-looking but non-redeemable voucher codes — do not attempt to redeem them |
| Webhooks | Sandbox webhook events are delivered to the URL configured against sandbox; production events never fire for sandbox orders |
| FX rates | Sandbox uses the same daily FX snapshot as production |
Promoting from sandbox to production
The minimum rehearsal before Stage 3 of your integration journey:
Swap hosts and credentials via a single config change
If your code requires more than one config change to switch envs, simplify it first. One env-var flip is the target.
Keep sandbox running alongside production for 2 weeks
After go-live, keep your sandbox integration active. When you need to test a change, the sandbox is where it goes first — always.
Separate webhook endpoints per env
https://your.example/webhooks/starship-sandbox and https://your.example/webhooks/starship-prod should be distinct routes. Even if they share a handler, the URL separation makes log tracing vastly easier.
Separate metrics and alerting
Tag your metrics with env=sandbox|prod. Never page on sandbox error rates; always page on prod ones.
Common pitfalls
| Pitfall | Consequence | Fix |
|---|---|---|
| Copy-pasting a curl example from docs into prod without changing the host | 401 or, worse, hitting sandbox with prod intent | Use $HOST env var everywhere, never hardcode |
| Whitelist request sent day-of-launch | Launch blocked 24–48 h | Request whitelist on Stage 0 |
| Prod credentials in a non-prod secret manager | Leak risk (dev laptop, CI logs) | Prod secrets live only in prod secret manager |
| Sandbox webhook URL configured against prod webhook (or vice versa) | Events go to the wrong handler | Enforce via a deploy-time check: prod-only URL for prod webhook |
Next
→ Versioning & Stability — what we guarantee won't change, and how we announce what will