Environments and sandbox

StrideHQ has two environments: the sandbox for building and testing, and production for real payments.

The two environments are completely separate. Nothing you do in the sandbox appears in production, and sandbox keys can't reach production data.

Your sandbox app

The sandbox has its own StrideHQ app, with its own login. When API access is switched on for your organisation, we set up your sandbox organisation and invite your Owner.

In the sandbox app you:

• create sandbox keys (shq_test_) in Settings > Developers > API keys
• add webhook endpoints and see every delivery
• see each key's requests from the last 30 days
• approve payment runs, exactly as your team will in production

What's in the sandbox

Your sandbox comes loaded with demo data, so you can try every endpoint straight away:

• creators in different states: fully onboarded, still onboarding, and on hold
• creators paid in different currencies
• invoices at each stage, including some with no PO and some over their PO amount
• POs with money left on them

The demo data is made up. No real person, company or bank account is involved.

What works differently

The sandbox behaves like production, with the same checks, statuses, errors and webhooks. The differences:

• No real money. Funding and payouts are simulated. Nothing is sent to a bank.
• No emails to creators. Emails the sandbox would send to creators go only to members of your organisation.
• Simulated funding and payouts. Test helpers fund a run and pay it out, or fail it, so you can test every stage. See below.
• Lower rate limits.

Test helpers

In production, a person approves, funds and releases every payment run in StrideHQ. You can approve runs in the sandbox app the same way. For automated tests, and for the steps that move money, the sandbox has test helpers:

Each helper sends the same webhooks as the real action would.

Test helpers only exist in the sandbox. They return 404 in production.

Reset your sandbox

You can reset your sandbox to the original demo data in Settings > Developers. This deletes everything you've created in the sandbox. Your keys and webhook endpoints stay.

What to test before going live

Test these in the sandbox, not just the happy path:

• A creator who can't be paid. Check your code handles can_be_paid: false and reads cannot_be_paid_reasons.
• Invoices left out of a run. Check you handle everything in skipped.
• Duplicates. Submit the same invoice twice and check you handle the 409.
• Retries. Repeat a request with the same Idempotency-Key and check you get the original response, not a second object.
• A run that's partly funded, using the fund helper with less than the total.
• Failed payments, using the fail helpers.
• Rate limits. Check your code waits and retries on a 429.
• Webhooks. Check you verify the signature and ignore duplicate events.

Keep environments apart in your code

• Keep the address and key together in one setting per environment, so you can't mix a sandbox address with a production key.
• Never use a production key on a developer's computer or in automated tests.
• Check the environment field from the organisation endpoint when your system starts, and stop if it isn't the one you expect.

Move to production

When your integration works in the sandbox:

1. Create a production key (shq_live_) in Settings > Developers > API keys, with the same scopes.
2. Switch the address to https://api.stridehq.ai/v1.
3. Add your production webhook endpoints. Each has its own signing secret.
4. Make sure your code doesn't rely on sandbox demo IDs. Production IDs are different.
5. Start small, for example by preparing one run and checking it in StrideHQ before going further.

Nothing you prepare through the API pays anyone until a person on your team approves the run in StrideHQ.

Next steps

• Quickstart: prepare your first payment run in the sandbox.
• Authentication: keys, scopes and rotation.
• Webhooks: every event, with example payloads.