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

# API Reference Overview

> How the BLIPS public API reference is organized inside Mintlify.

# API Reference Overview

The BLIPS API Reference is generated from a single public OpenAPI 3.1 document and then organized inside `docs.json` into core business families plus a trailing Sandbox APIs section for Public Test and demo-only reference surfaces.

The current generated Reference and Try It surface are bound to the Public Test Backend at `https://public-test.blips.network`.

## Current API families

* Platform Setup / Credentials
* Customers
* Accounts
* Same-Currency Transfers
* Cross-Currency Transfers
* Transactions
* Sandbox APIs

## Why this structure

This navigation mirrors the public integration flow more closely than a flat endpoint dump:

1. establish platform configuration
2. manage credentials and support verification
3. create and manage customers
4. attach accounts
5. run same-currency or cross-currency flows
6. inspect and act on transaction outcomes

Only the approved first-release endpoints appear in the primary navigation.

That means this first public surface intentionally excludes adjunct or retained reference-only routes that are not part of the approved launch set.

It also means the main business groups do not advertise `/platforms`, `/internal/*`, `/payments/*`, or legacy-only routes, while the trailing Sandbox APIs group stays limited to Public Test and demo-only helper surfaces.

## Sandbox API note

The current Sandbox APIs section contains:

* the platform-scoped Sandbox Lightning Network Execution Profile singleton, which configures execution-profile defaults read during `POST /quotes`
* `POST /sandbox/incoming-payments/simulate`, which creates Step 4 sandbox review cases and then feeds the existing transaction review flow through `GET /transactions`, `GET /transactions/{transactionId}`, `POST /transactions/{transactionId}/approve`, and `POST /transactions/{transactionId}/reject`

Neither sandbox surface is a second outward business API family.

For the incoming-payment simulation route, the three Step 4 scenarios are intentionally differentiated:

* `sanctions_hit` is reject-only
* `sender_kyc_not_approved` is reject-only
* `counterparty_info_incomplete` is manual-review-required before the demo operator should approve

## Source of truth

Every generated endpoint page in this section comes from:

```text theme={null}
openapi/blips-public-reference.yaml
```

That means changes to summaries, descriptions, schemas, examples, servers, auth, and webhook definitions should happen in OpenAPI first.