Sandbox Mode
How test and live are kept apart. For the walkthrough, seeded logins, and the authorize URL, see Sandbox.
One host, two worlds
api.wefunder.com serves both. The _live_ or _test_ segment in every credential and token decides which deployment handles the request:
| Identifier | Live | Sandbox |
|---|---|---|
| Client id | pk_live_… | pk_test_… |
| Client secret | sk_live_… | sk_test_… |
| Access token | at_live_… | at_test_… |
| Refresh token | rt_live_… | rt_test_… |
The two environments share no database, cache, job queue, payment credentials, or email infrastructure. A bug in sandbox cannot touch live data.
Realms
Within sandbox, each organization has its own realm: a self-contained copy of Wefunder at an unguessable host under wefunder-sandbox.com, with its own companies, offerings, users, and sessions. Realms never see each other, so the same email or company slug can exist in two realms without conflict.
What is different in sandbox
- No money moves. Payment, identity, and signature gates are driven by simulation tooling rather than real providers.
- Users are fixtures. Sandbox logins exist only in your realm. Your real Wefunder account never works there, and sandbox never exposes live data.
- Webhook endpoints are managed on live. Create an endpoint with
"mode": "test"through the live API and it is mirrored into your realm, which delivers your test events to it. See Webhook setup. - Separate rate-limit pool. Sandbox traffic does not consume your live budget.
- Installs live in your realm. Installing on the realm's company or syndicate (the install link on your realm host, or
POST /installationswith a test user token) creates an install that exists only in your realm, and the tokens minted from it areat_test_tokens. The portal's You row is live only. See Installing in your realm.
What is the same
The endpoints, scopes, error shapes, and access rules are the same code. Integration code written against sandbox runs unchanged against live once you swap credentials and install your app again on live.