SSettlaDocs

One Identity. Any Payment.

Settla documentation

Settla is identity and routing infrastructure for payments — the DNS for payments, the Google Maps for money. It resolves who a recipient is and where they can receive value, then recommends the best route. It never moves, holds, or settles funds.

Money has no addressing layer. To pay someone today you still need a raw, brittle, network-specific destination: a 34-digit account number, a 42-character wallet address on exactly the right chain, or the specific app the recipient happens to use. Settla is the neutral resolution layer that sits above every rail and turns “pay this person” into “send to this concrete, currently-valid, compatible endpoint.”

curl https://api.settla.network/v1/resolve \
  -H "Authorization: Bearer sk_test_..." \
  -H "Content-Type: application/json" \
  -d '{"alias":"@john"}'

The One Rule

Settla resolves identities, discloses endpoints, and recommends routes. It is never a custodian, wallet, processor, money transmitter, exchange, or chain executor. It holds no balances and moves no money. Amounts and fees are routing context only, never charges. Every route-recommendation response carries an explicit disclaimer saying so.

Mental models

Two analogies carry the whole product:

  • DNS for payments. You type example.com and the network resolves it to an IP without you knowing the topology. Settla resolves @john to a payment endpoint the same way.
  • Google Maps for money. Given a destination, Settla recommends the best route across rails (fee, speed, reliability) — but it never drives the car. Your existing money-movement system executes the transfer.

Three load-bearing principles

  • Identity is permanent. An Identity (a idn_ record) outlives any bank account or wallet it points to. The UUID is never freed.
  • Endpoints are replaceable. Banks and wallets come and go. Swap an Endpoint and the alias keeps resolving — no one has to “re-enter your details.”
  • Routes are dynamic. A route is computed fresh at request time against live telemetry, never stored.

What Settla is

  • An identity registry — permanent identities, each with a type (user, merchant, business, organization, …).
  • An alias system — human-friendly identifiers (@john, phone, email, merchant handle, payment link, QR) pointing to identities.
  • An endpoint registry — typed destinations (bank, crypto wallet, processor account, …) owned by identities, each with a privacy level.
  • A resolver — turns an alias into an identity plus the disclosed endpoints, filtered by privacy level, consumer scope, and consent.
  • A route recommender (V2) — scores candidate routes and returns a recommendation plus ranked alternatives with a machine-readable reason.
  • A developer platform — API, keys, webhooks, dashboards, and SDKs.

How it fits together

The platform is split into a write plane and read planes that share one set of runtime contracts (API-key hashing, field encryption, the Redis cache, the disclosure algorithm, the error envelope):

  • Control plane — the write side. Stores identities, aliases, endpoints, consent, keys, and webhooks; emits events. Never reads on the hot path.
  • Resolver — the read-only data-plane hot path that applies the disclosure filter and returns endpoints.
  • Route engine (V2) — calls the resolver with your credentials, scores the disclosed candidates, and recommends a route.

Where to go next

  • Quickstart — get a key and resolve @john in three steps.
  • Authentication — API keys, scopes, idempotency, and rate limits.
  • Resolve API — the core endpoint and its privacy-aware response.
  • Privacy & Security — privacy levels, consent, and the no-money-movement posture.