# DePix App > Non-custodial Pix payment gateway on the Liquid Network. Accept Pix payments > (checkouts, products and dated charges), on-ramp BRL to DePix and off-ramp DePix to Pix — > all via a REST API with API-key auth. Sandbox keys (`sk_test_`) work out of > the box; `simulate-payment` completes test checkouts without real money. DePix App never holds user funds or private keys: the API returns Pix QR codes and Liquid deposit addresses, and all signing happens client-side. Amounts are integer BRL cents. The payer's CPF/CNPJ (`payer_tax_number` / `taxNumber`) is required on money-moving endpoints. Naming: **DePix** is the BRL-pegged stablecoin on the Liquid Network; **DePix App** is this gateway service, built on top of it. Key facts: - API base URL: https://api.depixapp.com — every path below already carries its own `/api/` prefix, so the full URL is e.g. https://api.depixapp.com/api/checkouts - Auth header: `Authorization: Bearer sk_test_...` (or `sk_live_...`) - Fees (deposit 2% + R$ 0,99; withdrawal 1% + R$ 1,00 up to R$ 100, 2% above) are deducted from the amount — the DePix credited and the Pix paid out are NET. Current rates and worked examples: https://depixapp.com/en/#landing-fees - A charge (cobrança) is a product with `kind="charge"`: a payment link with a due date and optional late fine/interest, served at pay.depixapp.com/c/{id}, never listed on the merchant's public store. `list_products` omits charges unless you pass `kind=charge`. Docs: https://depixapp.com/docs/#charges - API keys have scopes: `merchant_read` (read checkouts/products/charges/account), `merchant_write` (create checkouts + product/charge CRUD), `wallet_read` (deposit/withdrawal status) and `wallet_write` (on/off-ramp money movement; never granted by default) - Idempotency: send an `Idempotency-Key` header on POST /api/deposit, /api/withdraw, /api/checkouts - Errors: structured `error: { code, message, request_id, retry_after?, docs_url }` alongside the legacy `response.errorMessage` (Portuguese) - Rate limits return 429 with `Retry-After`; every response carries `X-Request-Id` - Webhooks are HMAC-signed (`X-DePix-Signature: t=,v1=`): checkout.* events for all merchants, plus deposit.*/withdraw.* events for API-key operations; status can also be polled via `GET /api/deposits/:id` and `GET /api/withdrawals/:id` (terminal deposit status: `depix_sent`; full status enums in the docs and OpenAPI) ## Docs - [API reference (Markdown)](https://depixapp.com/docs.md): full API documentation, agent-friendly - [OpenAPI 3.1 specification](https://depixapp.com/openapi.json): machine-readable schema of the REST API - [Agent manifest](https://depixapp.com/.well-known/agent.json): capabilities, auth and endpoints summary - [API reference (HTML, English)](https://depixapp.com/docs/en/): human-readable, code examples in 8 languages - [API reference (HTML, Portuguese)](https://depixapp.com/docs/): versão em português ## MCP server — one server, two levels There is ONE DePix MCP server, **`@depixapp/mcp`** (Apache-2.0, registry id `io.github.depixapp/depix-mcp`). It registers **62 tools**. Which of them work depends only on where it runs and whether that process holds a wallet seed: - **Level 1 — hosted, 26 tools, receive.** `https://mcp.depixapp.com/mcp` (MCP Streamable HTTP, stateless). Zero install: connect as an OAuth 2.1 connector, or send `Authorization: Bearer sk_test_…`. Twenty merchant tools — it reads and creates checkouts, products and charges but never creates deposits or withdrawals, so it cannot move funds on its own — plus six support-ticket tools (open, get, list, reply, close a support ticket, and attach a file to one). This deployment holds no seed, so the 29 `wallet_*` tools are structurally absent from it. - **Level 2 — local, 62 tools, the full wallet.** `npx -y @depixapp/mcp` over stdio, run where the agent lives. Same 26 tools plus 29 `wallet_*` tools that hold, sign and MOVE FUNDS: balances and addresses, Pix on/off-ramp, send, quote/convert, cross-network stablecoin shifts, Lightning pay/receive (settled through Boltz swaps, not a native DePix Lightning rail), gift cards, guardrails, recovery and diagnostics — plus 7 agent-local tools (register_account, agent_status, verify_domain, configure_depix_rail, activate_key) that self-onboard the account on this machine, toggle its DePix direct rail and switch it to live. Env: `DEPIX_API_KEY` (gateway tools), `DEPIX_WALLET_PASSPHRASE` (wallet tools), `DEPIX_WALLET_DIR` (optional). Without a configured wallet those tools stay listed and return a typed `wallet_not_configured` error. First run is a human terminal ceremony, never an MCP tool — the mnemonic must not transit model context: **`npx -y @depixapp/mcp init`** creates or restores the wallet, sets the spending guardrails, and registers the server with the AI hosts it finds on that machine, so there is no `mcpServers` block to paste by hand (it falls back to printing one). The rite asks for no API key and never writes the passphrase into a host config: the OS keychain holds the unlock key, and the agent opens its own DePix account later with `register_account`. The split between the levels is custody, not withheld features: signing happens in-process, so whichever process runs a wallet tool IS the seed holder, and DePix App holds no seeds. stdio is the only default-safe transport for level 2 — the server loads the seed process-wide and has no auth of its own. Four more human subcommands sit beside `init`, none of them MCP tools either: `backup` re-displays those 12 words under the same terminal-only rite, `login`/`logout` link and unlink the OPERATOR's own DePix account through a browser sign-in that returns to 127.0.0.1 on that same machine (on 2.8.0 and 2.8.1 it needs `DEPIX_WORKOS_CLIENT_ID` set to the sign-in application; from 2.8.2 the right id is baked in), and `account status|use` reports and selects which account the server acts as — `DEPIX_API_KEY` in the environment outranks any selection. - [npm package](https://www.npmjs.com/package/@depixapp/mcp): `npx -y @depixapp/mcp` - [MCP repository](https://github.com/depixapp/depix-mcp): source, README and usage ## Agent wallet SDK (code-level lineage) `@depixapp/mcp` is the surface to reach for when an agent is driving. When YOU are writing the code, the same wallet engine is also published as **`@depixapp/sdk`** (TypeScript, ESM, AGPL-3.0, 1.2.2) — wallet-first and intent-based: create/restore a wallet from a seed the agent controls, then call `convert()`, `quote()`, `send()`, `receive()`, `deposit()` and `withdraw()`. Routing (SideSwap / Boltz / SideShift), settlement and crash-recovery are built in. Install it with `npm install @depixapp/sdk`. The tarball ships `AGENTS.md`, the start-here guide for agents — routing table, units and examples. - [npm package](https://www.npmjs.com/package/@depixapp/sdk): `npm install @depixapp/sdk` ## Optional - [Full documentation in one file](https://depixapp.com/llms-full.txt): llms.txt plus the entire Markdown API reference inline - [BTCPay Server plugin](https://depixapp.com/btcpay/en/): accept DePix in BTCPay - [Blog](https://depixapp.com/blog): product updates (Portuguese; English at /blog/en/)