Concepts
Sandbox & going live
Test accounts and their fake balances, mock vs live models, and the tier ladder.
Real money — a real user’s balance — only moves once an app goes live. Before that an app runs in sandbox, where the balance is fake. Every new app starts there.
The ladder
| Tier | Review | Can connect | Money |
|---|---|---|---|
| sandbox | none — instant | your test accounts (signed in, or picked by you or a teammate on test_allowlist) | fake, non-withdrawable |
| limited live | lightweight — hours | anyone | real balances, with the limits below and a “new app” note on the consent screen |
| full live | deeper — manual | anyone, higher volume | no tier limits; requires a verified domain + entity info, KYB at higher volume |
Limited live limits
| Limit | Value | When it’s hit |
|---|---|---|
| Spend cap per connection | $10 by default, $25 at most | 402 allocation_exhausted; the user can raise it, up to $25 |
| Spend per connection per 24 hours | $5 | 429 daily_limit_reached |
| Spend across all your connections per 24 hours | $250 | 429 app_spend_limited and an app.spend_limit_reached webhook |
The limits apply only to live connections (sandbox ones spend fake money) and are worked out from your app’s current tier on every call, so they lift the moment the app is promoted to full live — connections that ran out only because of the $10/$25 cap become usable again. A connection’s own cap and daily limit still apply if they’re lower.
Full live isn’t open yet. Its domain and entity checks are still being built, so for now apps go as far as limited live and keep its limits.
Wind can also suspend any app at once, on spend anomalies, revocation spikes or
chargebacks: its calls return 403 app_suspended, its tokens stop refreshing
and it can’t take new connections until Wind lifts it. Wind’s platform risk
engine runs on every app too, freezing or throttling a connection whose spend
spikes against the app’s normal pattern.
Test accounts
Sandbox apps are used by test accounts: fake Wind users you create, each with a fake balance. They sign in to Wind like anyone else, so you (or a tester you share the login with) can try your app end to end — connecting, spending, running out, approving a cap increase, revoking — without real money.
Create them on the console’s Sandbox page: give each a name and a starting
balance, and Wind generates a sign-in email on test.usewind.app and a password.
The password is shown once; reset it there if it’s lost. Up to 25 per developer.
- A test account signs in with its password only. Its address never gets email, so sign-in links and password-reset emails don’t work for it.
- Its Wind dashboard shows its fake balance, and it can set that balance itself (so can you, from the Sandbox page).
- It can connect only to your sandbox apps — never a live app, another developer’s app, real money, or developer mode.
- Removing one signs it out, revokes its connections, and keeps its usage history.
You can also skip signing in as one: open your sandbox app’s consent screen as
yourself (or as a teammate on the app’s test_allowlist) and it asks which of
your test accounts to connect as. Either way the connection, its tokens and
every charge belong to the test account, never to a real wallet. If you have no
test accounts yet, the consent screen makes Test account 1 with $500.
The Sandbox page also totals what your test accounts spent, by account and by
app, in fake currency. Allocations, holds, allocation_exhausted, and the four
ledger numbers all behave exactly as in production, computed from a synthetic
price sheet.
Connections made before test accounts existed belong to the real account that approved them and keep working. New sandbox connections are always made by a test account.
Provider mode
Set per app, in App → Integration → Provider mode.
| Mode | Returns | Cost | For |
|---|---|---|---|
| mock (default) | deterministic canned completions (and a canned tool call when you pass tools), real token counts + cost block | zero | OAuth, token rotation, ledger shape, holds, exhaustion, webhooks, errors |
| live models | real OpenAI, Claude and Gemini output, billed to the test account’s fake balance | Wind still pays the provider | developing prompts, picking a model |
Live-model sandbox calls are the only real cost, so Wind covers $1 of real provider cost per 24 hours per developer, shared by all their test accounts across all their apps (allowlisted teammates who connected before test accounts existed each keep their own $1). Mock mode has no such limit.
Your own provider keys
To keep testing on live models past Wind’s $1, add your own OpenAI, Anthropic or Google key on the console’s Sandbox page. Once Wind’s allowance for the day is used up, a live-model call runs on your key for that model’s provider instead — billing, limits and the ledger still behave as usual against the test account’s fake balance, and your provider bills you directly. Calls on your key don’t count toward Wind’s $1. Your keys are encrypted, never shown again after you save them, and only used for your own sandbox apps.
Past Wind’s allowance, a call whose provider you haven’t added a key for
returns 429 sandbox_live_cost_limited. Add a key, switch the app to mock mode,
or wait for the 24-hour window to roll over.
Free credits for new users
Once your app is live, Wind pays for each new user’s first usage of it, so people can try your app before adding a card. Every live app gets a monthly pool (currently $50, refilling on the 1st, UTC). A user’s calls on your app are free until they’ve used $2 there (or $10 across all Wind apps); after that their own balance pays, as usual.
- Nothing changes in your integration: allocations, holds, limits, the ledger
and the
windcost block behave the same. - Each call is paid by one source — the pool or the user’s wallet — never both.
- Free calls are charged at cost: they earn you no margin.
- Your console’s app Overview shows how much of this month’s pool is used; the consent screen tells eligible users their first usage is free.
- Sandbox apps and test accounts never use the pool.
Wind may change these amounts.
Going live
Request promotion from App → Overview → Go live in the console. The card shows a checklist first; the required items are:
- an API client and at least one redirect URI
- at least one registered feature
- the allowed models chosen
A logo and live models are recommended but not required. Without a logo the consent screen shows your app’s initial.
Submitting creates a go-live request for the next tier up (sandbox →
limited-live, and later full-live once it opens) and puts it in Wind’s
review queue. Your app keeps
its current tier until the request is reviewed, and you can only have one request
pending at a time. When it’s approved, the app moves to the new tier and its
provider mode switches to live; if it’s rejected, the app stays where it was and
you can apply again.