Thesettlementlayerforthemachineeconomy.

Developers

Samples that cannot go stale

Runnable samples and reference apps

Thirteen build-checked samples and four cloneable reference applications, extracted straight from compiled source.

Copy code out of the documentation and you get the same lines that continuous integration compiles and measures. The site build re-extracts every published block from its named sample file and region, so a page that disagrees with its sample fails the build. Thirteen samples cover TypeScript, Python, Go, Java, C#, Swift and Rust across Express, FastAPI, Spring Boot and Next.js. One runner drives four reference applications through a buyer, seller, merchant and marketplace journey on a local emulator.

What it does

Thirteen sample projects sit under platform/docs/samples, each declared in platform/docs/samples.kvx with its install, build and run commands, the environment it needs, and a hard budget for how many lines of LayerX integration code it adds. The documentation site build extracts every published code block straight from the named sample file and region, so a page that disagrees with its sample fails the build. Separately, platform/examples/reference-apps.json declares four complete Node.js applications (a buyer agent, a paid API, a merchant shop and a programs marketplace), each with one command for a local emulator and one for beta. One runner, platform/examples/run-reference-apps.mjs, checks that manifest and drives all four through a single end-to-end journey.

Key capabilities

  • Samples cover TypeScript, Python, Go, Java, C#, Swift and Rust, plus Express, FastAPI, Spring Boot and Next.js.
  • Two mobile samples show the same first payment on iOS and Android, holding no long-lived credential.
  • Every documented code block is re-extracted from its sample file, so page and code cannot drift apart.
  • Each sample declares a nine-line integration budget; the docs build fails a sample that exceeds it.
  • Four reference applications each carry one emulator command and one beta command, declared in one manifest.
  • The runner's emulator scenario starts a local emulator, derives its inputs from real receipts, then tears it down.

Who it's for

Developers adding LayerX payments to an application or service they already run.

Why it matters

The code a developer copies out of the documentation is the same code that is compiled and measured in continuous integration, so it does not go stale silently. The emulator scenario runs the whole buyer, seller, merchant and marketplace journey on one machine without any issued credential.

Differentiators

The published integration line count is enforced rather than advertised: platform/docs/build/build_site.py fails the docs build when a sample's measured region exceeds its declared budget, and the generated index records the current samples at four to nine lines against a budget of nine. The reference runner refuses drift it finds in the manifest, including a changed command shape, a missing start: script, a protocol version other than 3, or a source file that has lost its declared symbol, and it rejects a reference application that carries fixture or browser secret surfaces.

Outcomes

  • Each sample keeps its LayerX integration within a nine-line declared budget.
  • Run the full buyer, seller, merchant and marketplace journey on one machine.
  • Clone a reference application with one emulator command and one beta command.

Technical notes

  • Runtime floors: Node.js 22 or newer, Python 3.11 or newer. Other samples need Go 1.21, JDK 21 with Maven, Swift 5.9, .NET 8 or a Rust toolchain.
  • No first-payment, paid-endpoint or paid-route sample targets the emulator. Each needs issued values in the environment: LAYERX_API_URL, LAYERX_API_TOKEN and the move inputs for the payment samples, or the twenty-one declared seller keys for the paid-endpoint samples. No sample runs credential-free.
  • The line budget counts only the LayerX integration region. It excludes the application's own error-handling idiom, data model, storage adapter and reporting.
  • Only first-payment-typescript, paid-endpoint-express and paid-route-next are npm workspace members. The rest build with their own native toolchain, all driven by make platform-test-docs.
  • The reference applications are npm workspaces that build from the repository root (npm ci, then npm run build). The emulator scenario also needs the layerx CLI, resolved from $LAYERX_BIN, build/bin/layerx or PATH; the beta scenario needs operator-supplied LAYERX_TESTNET_* values.
  • merchant-checkout is a workspace compatibility name for merchant-shop. platform/examples/agent-spend and platform/examples/agent-program-call exist beside the four applications but are not in the manifest, and the runner does not drive them.
npm ci
npm run build
node platform/examples/run-reference-apps.mjs --check
node platform/examples/run-reference-apps.mjs --scenario emulator

More in Developers

Build on Paxeer.

Give your agent a wallet, set its policy, and settle your first call on LayerX.