Build
Building on OpenApps.
Four ways in, from least to most involved: let people sign in to your site with OpenWallet, get paid by their agents, charge OpenApps credits from an app in the suite, and list your app's operations so any agent can find and run them.
Last updated: 5 October 2026
Sign in with OpenWallet.
Live OpenWallet ID is a standard OpenID Connect provider. Anyone can use it without registering first: your client id is the URL of a metadata document you publish. People sign in with Google or an email code plus a passkey or TOTP, and your site gets a private identifier for them. They share their email only if they tick it.
| Value | |
|---|---|
| Issuer | https://wallet.openapps.network |
| Discovery | https://wallet.openapps.network/.well-known/openid-configuration |
| Client id | An https URL serving your client metadata document. No registration. |
| Flow | Authorization code with PKCE (S256) |
| Scopes | openid, and optionally email, xrpl (an XRP Ledger address), nostr (an npub) |
| ID tokens | ES256, keys at /oidc/jwks.json |
| Subject | Pairwise: the same person has a different sub on every registrable domain, so two sites cannot match their users up. |
The full guide, with a working example, is Sign in with OpenWallet.
Get paid by agents.
Live If you run an HTTP API or an MCP server, you can charge agents that pay with OpenWallet, or with any other x402 client. Answer a request with 402 Payment Required and an x402 challenge in XRP or RLUSD; the agent's wallet pays within its owner's limits and retries, and you return the resource with a receipt. The open-source @openwallet/x402-xrpl library asks for the payment, verifies it on the ledger and issues the receipt. See Accept payments.
Accounts and credits.
Live for apps in the OpenApps suite. Every app shares one account service, so a person signs in once and spends one balance everywhere. App keys are issued to apps in the suite; if you are building one, write to contact@openapps.network.
| Value | |
|---|---|
| Base URL | https://accounts.openapps.network |
| User tokens | EdDSA JWTs, 15 minutes, verified locally against /.well-known/jwks.json. Refresh tokens rotate; reusing an old one revokes the whole family. |
| Sign-in methods | Google, OpenWallet, Ethereum wallets, Nostr and Telegram. Ask GET /v1/auth/methods before drawing a sign-in screen. |
| Top-ups | Card (Stripe), Ethereum, Lightning, and Apple and Google in-app purchase. GET /v1/payments/packages lists the packages. |
| Errors | {"error": {"code": "insufficient_balance", "message": "…"}} with 400, 401, 402, 404, 409, 429 |
The calls an app makes
| Call | Auth | What for |
|---|---|---|
GET /v1/me | user | The person, their linked sign-ins, balance and referral code |
GET /v1/credits/balance | user | The balance, before offering a paid feature |
POST /v1/credits/deduct | app key + user | Charge for work that succeeded: { amount, reason, idempotency_key } |
GET /v1/credits/history | user | The ledger, newest first, with which app charged each entry |
POST /v1/payments/stripe/checkout | user | A card top-up; poll /v1/payments/topups/{id} for the result |
Three rules for charging
- Charge from the server that did the work, after it worked. An app key can charge any signed-in person, so it never ships in a desktop app, an extension or a web page. A service that only forwards charges is no safer than shipping the key; the code that knows whether the work succeeded is the code that charges.
- One idempotency key per piece of work. A replay returns the original result with
"replay": trueand charges nothing. - Write
reasonfor the person. It is shown in their history as what the credits bought, so name the feature ("watermark removal"), not the function that called it.
List your operations for agents.
Building An app reaches agents by publishing operations into the OpenApps MCP catalogue, not by adding tools. An operation is a contract:
| Field | What it says |
|---|---|
id | domain.verb, for example doc.classify_and_split |
| Input and output | Typed schemas. Inputs are files by handle or URL, never by path. |
| Invariants | What the operation guarantees about its result, and what it explicitly does not establish |
| Cost | How the price is worked out, so a quote can be given before running |
| Effects | reads, writes, sends or spends. This is what OpenWallet decides on. |
| Evidence grade | How far the result can be relied on, from best-effort to audited by an independent checker |
| Aliases | What people actually type, in all eight of our languages (“split invoices”, “拆分发票”) |
To list one:
- Add the contract, with aliases in the eight languages, and an auditor if any guarantee is meant to back money.
- Add at least ten labelled search queries that should find it. The catalogue's search must still find the right operation in its top five for 95% of all labelled queries.
- Pass the operation's conformance cases and the search check.
- Deploy. A new operation needs no new tool and no change to any tool description, so agents pick it up without re-approving anything.
Building something you would like listed? Join the builders' list.
Writing an MCP server for an app.
If your app runs on people's own machines and ships its own MCP server, follow the conventions in the MCP reference. The short version:
- Speak MCP
2026-07-28, and keep theinitializehandshake for older clients. - Name tools verb first, in snake_case, saying what they act on. Give every tool a title, all four annotations, an output schema, and a description under 1 KB.
- Return refusals as results with
isErrorand a stablecode, never as protocol errors. - Take paths in and give paths out, inside the folders the person named. Never inline file contents.
- Add a
report_problemtool that never sends anything without the person's say-so. - Keep the default tool list to fifteen or fewer and its definitions to about 2,500 tokens.