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

# Onboard

> Credentials, custodian coordination, and connectivity test to get your institution connected.

Onboarding for an institution is mostly coordination: your custodian does most of the infrastructure work, and you confirm readiness on your side (counterparty directory, optional backend deployment).

## Onboarding checklist

<Steps>
  <Step title="Receive credentials">
    Musubi provisions:

    * **Canton Party ID** — your identity on the settlement network
    * **JWT signing credentials** — for API and console authentication
    * **Network connectivity details** — TLS certificates and endpoint references (if you run your own backend)
  </Step>

  <Step title="Confirm custodian readiness">
    Check with your custodian that they have:

    * Connected their node to the settlement network
    * Set up your institutional custody account
    * Whitelisted the Musubi settlement address
    * Sufficient stablecoin balance for your expected volumes

    Your custodian's completion of the [Custodian onboarding](/custodian/integration/deploy) is a prerequisite — settlement can't fire without their co-signature and liquidity.
  </Step>

  <Step title="(Optional) Deploy your backend">
    Institutions with custom treasury automation may deploy their own Musubi backend:

    * Configure with your Party ID and JWT credentials
    * Connect to your PostgreSQL instance
    * Establish TLS connectivity to the settlement network

    Most institutions skip this step and use the console + statements path, coordinating through their custodian's infrastructure. Only stand up your own backend if you need [Programmatic Access](/institution/integration/programmatic-access).
  </Step>

  <Step title="Connectivity test">
    * `GET /health` — backend is running and connected to the network
    * `GET /whoami` — confirms your Party ID and role
    * Create a test order on testnet and verify it reaches SETTLED
  </Step>

  <Step title="Counterparty onboarding">
    For each counterparty institution you'll transact with, record their Party ID + their custodian's Party ID in your existing counterparty directory. These reference fields go on every FXOrder you create.
  </Step>
</Steps>

## Testnet validation

Scenarios to run before production:

1. **Happy path** — create order → receive quote → accept → verify SETTLED status
2. **Cost guard** — set `source_amount_max` below the expected quoted amount → verify `SLIPPAGE` rejection
3. **Expiry** — create order with short `expires_at` → no quotes accepted → verify EXPIRED
4. **Cancellation** — create order → cancel before quote acceptance → verify cancellation
5. **Reconciliation** — match `transaction_hash`, `settled_at`, and amounts across your accounting system
6. **Statement export** — once you've settled a few testnet orders, run your first statement download and confirm the fields line up with your general ledger

## Next steps

* Daily operation — your treasury team uses the [Console](/institution/integration/console)
* Reconciliation — [Statements](/institution/integration/statements) feeds accounting
* Custom integration — [Programmatic Access](/institution/integration/programmatic-access) for TMS/ERP