Framework selector
Choose a backend recipe. Every runtime uses the same ATM flow: create checkout, verify events, and fulfill from a trusted backend.
Compatible with the closed-beta ATM app APIs and versioned ATM event headers. Check atm-api-version on every webhook or XRPC receiver event.
Choose a runtime
ATM docs are API-first. The framework recipes below all teach the same concepts in the same order: install the SDK, create checkout from a trusted backend, verify a webhook or XRPC receiver event, fulfill payment or ticket state, and run a local test fixture.
Full-stack route handlers for checkout and webhooks.
Open guideHonoLightweight Hono route handlers for AT Protocol-style app servers.
Open guideCloudflare WorkersWorkers-style fetch handlers and durable idempotency guidance.
Open guideExpressRaw-body HTTP webhook verification for Express apps.
Open guideFastifyFastify route shape and raw-body verification notes.
Open guideGeneric Node HTTPLowest-common-denominator server contract for agents and custom servers.
Open guideArchitecture first
ATM is framework-agnostic. The durable integration is the server contract: create checkout from a trusted backend, redirect or embed the ATM-hosted checkout, verify ATM events, deduplicate delivery ids, and fulfill from ATM truth. Next.js is one polished example of that architecture, not the architecture itself.
Server first
Checkout envelopes, service-auth, webhook secrets, buyer assertions, and fulfillment mutations stay on your backend.
Client light
Browsers show app UX, call your backend, and return from checkout; they do not build private envelopes.
Events as truth
HTTP webhooks and optional XRPC receivers drive fulfillment. Browser returns are only UX hints.
Framework optional
Next.js, Express, Fastify, Hono, Workers, Go, or Python can all implement the same flow.
Portable backend contract
Every ATM app integration, regardless of framework, has the same six server-side steps.
- 01
Create app order
Store your app order, ticket hold, product selection, or subscription intent in your own backend.
- 02
Check payability
Call ATM payout status before exposing an active payment button.
- 03
Confirm approval
Call requestRecipientApproval and send the creator to ATM if the app-recipient scope is pending or needs review.
- 04
Start checkout
Build the private ATM checkout envelope and call ATM from your backend.
- 05
Verify event
Verify signed HTTP webhooks or optional XRPC receiver service-auth.
- 06
Fulfill idempotently
Deduplicate by delivery id and ATM payment id before changing app state.
Runnable starters
Start with a runnable starter when your stack matches one of the high-priority paths. Use the recipe pages when you need to port the same ATM contract into another framework.
| Next.js starter | examples/atm-next-starter - route handlers for checkout and webhooks. |
|---|---|
| Hono / Workers starter | examples/atm-hono-worker-starter - lightweight Hono app with Workers-style fetch export. |
| Generic Node starter | examples/atm-node-app - minimal HTTP server with checkout, status, webhooks, optional XRPC receiver, and Tickets calls. |
What to copy
- Server-only ATM client setup.
- Recipient payability check before showing checkout.
- Creator app approval check before creating checkout.
- Checkout initiation with app order id in private metadata.
- Raw-body webhook verification.
- Delivery id deduplication before fulfillment.
- Payment id stored beside the app order.
- The same boundaries if you port the starter to another backend stack.
What to replace
- Replace sample service-auth minting with a real AT Protocol service-auth flow.
- Replace in-memory/no-op order functions with your database.
- Replace app.example URLs with registered app origins.
- Replace generic product purchase copy with your app module policy.
- Pin @atmosphere-money/app-node@beta and review changelog notes before updating.