# API overview

The MoonPay Wallets API uses different credentials for app management and runtime requests. Read this
before the [generated endpoint reference](/api-reference). It tells you which
parts you'll actually call, and with what.

<Warning>
  Standard wallet creation and signing involve the user's client SDK, not a single REST request authenticated by an app secret key. Your backend verifies callers and reads wallet addresses; separately authorized delegated signing has its own contract. For a client-signing trading flow, follow the [DeFi Trading App recipe](/recipes/wallets/defi-trading-app).
</Warning>

## Base URL

```
https://x-api.moonpay.com
```

All public endpoints live under `/v0/`.

## API credentials by operation

| Surface | Paths | Credential | Called from |
| --- | --- | --- | --- |
| **Organization management** | `/v0/management/*` | Organization key (`Authorization: Bearer moon_org_...`) with the operation's scope | Your backend creates and configures apps, then issues app keys |
| **SDK / browser** | `/v0/sdk/*` | Publishable key (`Authorization: PublicToken moon_pk_...`), plus the user's access token (`X-MoonX-Access-Token`) on session-scoped routes | The React SDK drives these for you; call directly only if you're building a custom client |
| **Market data** | `/v0/data/*` | App secret key (`X-API-Key`), except the publishable-key-acceptable bulk balance route | Your backend; see [Market data](/data/overview) |
| **Swaps** | `/v0/swaps/*` | App secret key (`X-API-Key`) | Your backend; see [Swaps](/swaps/overview) |
| **Signer lifecycle** | `/v0/wallets/ephemeral-signers/`, `/attestation`, `/{api_pub}` | App key and user session; provisioning/revocation also require operation-scoped presence. `/policy` needs only the app key | The user manages their own signers through the SDK |
| **Server-only** | `/v0/compliance/*`, `/v0/wallets/ephemeral-signers/sign`, `/v0/wallets/ephemeral-signers/me/wallets` | Secret key (`X-API-Key: moon_sk_...`) | Your backend - never the browser |
| **Step-up (presence)** | Sensitive wallet operations (signing, key export, passkey removal, signer provisioning/revocation) | Operation-scoped `X-MoonX-Presence`, with the required user session. Accepted proof sources depend on the operation and protection model | The SDK drives passkey, OTP, or eligible identity-backed authorization as supported |

## Which key when

* **Organization key** (`moon_org_...`): manages apps in one organization within its scopes. Backend-only. See [Organization API keys](/get-started/rest-api/organization-api-keys) for scopes and [Provision apps](/get-started/rest-api/provision-apps) for the setup flow.
* **Publishable key** (`moon_pk_test_...` / `moon_pk_live_...`): identifies your
  app. Ships in frontend code. On its own it grants nothing sensitive; the real
  auth boundary on SDK routes is the user's wallet-session JWT.
* **Secret key** (`moon_sk_test_...` / `moon_sk_live_...`): the app-level,
  high-privilege credential. Server-side only; revealed once at creation.
  Publishable keys sent to secret-only endpoints get `403 secret key required`.
* **User tokens**: the access token (1h) authenticates a user's session;
  the identity token (10h) carries OIDC-style claims; both are ES256 JWTs your
  backend [verifies against your app's JWKS](/authentication/user-authentication/sessions/backend-verification)
  (`GET /v0/sdk/.well-known/jwks/{app_id}`), no verification round-trip to MoonPay Wallets.

## Typical backend calls

```bash
# Verify nothing: fetch your app's JWKS once and verify tokens locally
curl https://x-api.moonpay.com/v0/sdk/.well-known/jwks/your_app_id

# Who is this access token? (session-scoped SDK route)
curl https://x-api.moonpay.com/v0/sdk/auth/users/public/me \
  -H "Authorization: PublicToken moon_pk_test_your_publishable_key" \
  -H "X-MoonX-Access-Token: EXAMPLE_ACCESS_TOKEN"

# Compliance: block an end user (secret key only)
curl -X POST https://x-api.moonpay.com/v0/compliance/users/blacklist \
  -H "X-API-Key: moon_sk_test_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "user_id_to_block"}'
```

Server-side signing on behalf of a user goes through
[ephemeral signers](/wallets/ephemeral-signers/overview): the
secret key plus the agent's own Ed25519 signature, with signatures produced
inside an attested enclave.

## Not a public API

The MoonPay Wallets Dashboard uses `/v0/developer/*` routes with a human session cookie for
organization and member administration. Organization-key issuance and revocation
also use [owner-authenticated endpoints](/get-started/rest-api/organization-api-keys#owner-key-management).
Partner automation uses `/v0/management/*` with an organization key.
Wallet creation and MPC signing ceremonies under `/v0/wallets/key/*` and
`/v0/wallets/sign/` are likewise driven by the SDK's cryptographic protocol,
not callable as simple REST requests.

<Info>
  The full endpoint list, request/response schemas, and an interactive
  playground live in the [API Reference](/api-reference), generated from the
  backend's OpenAPI spec.
</Info>