> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stableyard.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments

> Sandbox and production: base URLs, what is isolated between them, and what to prove before you go live.

Stableyard runs two environments. They share no data, no credentials and no accounts.

| Environment | Base URL | Purpose |
| - | - | - |
| Sandbox | `https://staging-api-v2.stableyard.fi` | Build and rehearse |
| Production | `https://prod-api.stableyard.fi` | Live money |

Every API reference page carries a server selector, so a request copied from the documentation can be switched between environments without editing it.

## What is isolated

Everything that identifies or holds value:

* **Credentials.** An app ID and secret belong to exactly one environment. A sandbox key sent to production fails authentication rather than acting.
* **Accounts.** A UPA created in sandbox does not exist in production. Your `externalUserId` mapping has to be per environment.
* **Webhook endpoints and signing secrets.**
* **Enabled capabilities.** A capability switched on in sandbox is not automatically on in production. `GET /v2/partners/config` answers per environment and per credential.

Provisioning is per app and per environment, including the single dashboard owner email for each.

## What differs beyond isolation

Sandbox is not a mirror of production. Two differences matter when planning.

**Networks.** Sandbox uses test networks. Chain ids differ, and an address or asset that is valid in one is not valid in the other. Never carry a chain id across.

**Provider behaviour.** Fiat rails run against provider sandboxes where one exists. Some corridors cannot be rehearsed end to end outside production, so a first production transfer is also the first real test of that corridor. Plan a supervised low-value transfer rather than a full launch.

## Moving to production

Before you switch a base URL:

<Steps>
  <Step title="Read config in production">
    `GET /v2/partners/config` with the production credential. Capabilities are granted per environment, so do not assume anything carries across.
  </Step>

  <Step title="Re-register webhooks">
    New endpoint, new signing secret. Verify a signature before you trust a payload.
  </Step>

  <Step title="Recreate accounts">
    Accounts do not migrate. Your first production call for a customer is a create.
  </Step>

  <Step title="Rehearse the failure paths">
    Underpayment, duplicate payment, late receipt and expiry are the states that need a human. Confirm your side handles each before volume arrives.
  </Step>
</Steps>

<Warning>
  An app secret is a server-side credential in both environments. It must never reach browser, mobile or agent-visible code. Client-side integrations exchange a short-lived session instead.
</Warning>

## Next

<CardGroup cols={2}>
  <Card title="Authentication" icon="key" href="/authentication">
    Credentials, permissions and client sessions.
  </Card>

  <Card title="Webhooks" icon="bell" href="/webhooks">
    Events, delivery and signature verification.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.