Architecture Overview

Platform map

This page is the shared systems view: frontend, API, facilitator, SDK, OpenDexter, and Dexter Lab as one coherent platform rather than isolated repos.

Dexter's canonical public docs need a high-level architecture page because the platform now spans multiple first-class surfaces.

Core Platform Layers

Frontend and product surfaces in dexter-fe
Public API and shared backend flows in dexter-api
Settlement and chain execution in dexter-facilitator
Developer integration surface in @dexterai/x402
Agent and discovery tooling through OpenDexter-oriented x402 flows
Builder product in Dexter Lab

Service Map

flowchart TD
  users[UsersAndAgents]
  dexterFe[DexterFE]
  opendexter[OpenDexter]
  dexterApi[DexterAPI]
  facilitator[DexterFacilitator]
  sdk[DexterX402SDK]
  lab[DexterLab]
 
  users --> dexterFe
  users --> opendexter
  users --> sdk
  dexterFe --> dexterApi
  opendexter --> facilitator
  sdk --> facilitator
  lab --> dexterApi
  lab --> facilitator
  dexterApi --> facilitator

What Each Surface Does

`dexter-fe`

The main public frontend and docs shell. This is where users encounter:

the site and docs
facilitator landing pages
marketplace-facing discovery surfaces
user-facing routing into the rest of Dexter

`dexter-api`

The shared backend and orchestration layer. It owns public system behaviors such as:

realtime session minting
wallet resolution
connector OAuth
public and internal API glue
x402-related billing and orchestration hooks

`dexter-facilitator`

The settlement engine behind the x402 flow. It is responsible for:

verifying payment payloads
sponsoring fees where supported
settling transactions on-chain
publishing a live support matrix through /supported

`@dexterai/x402`

The merchant and client integration surface. It gives developers:

client fetch wrappers
browser and React support
server middleware
lower-level manual control
access-pass and pricing primitives

OpenDexter

The public discovery and payment path for x402 resources. As the broader generic MCP story shrinks, OpenDexter becomes the cleaner public tooling layer to document.

Dexter Lab

The builder product for creating, deploying, verifying, and publishing paid APIs. It sits closer to the product creation workflow than the lower-level SDK does.

Why This Page Matters

Without an architecture page, readers are forced to infer the system from scattered repo READMEs and isolated docs pages. That is one of the reasons the old docs felt smaller than the real platform.

How The Main Flows Connect

Merchant flow

A developer protects an endpoint with @dexterai/x402
Settlement routes through the facilitator
Discovery can happen through OpenDexter-related surfaces

User or agent flow

A user or agent discovers a paid resource
The resource returns 402 Payment Required
Payment is prepared through an x402-compatible client or OpenDexter flow
The facilitator verifies and settles
The resource responds

Builder flow

A creator uses Dexter Lab to create a resource
Dexter Lab uses the broader platform services
Payments still settle through the same facilitator layer
The resource becomes part of the broader discovery surface

Architecture Boundaries The Docs Should Respect

The docs should explain platform relationships without turning every page into an internal implementation dump.
The facilitator pages should own settlement and network details.
The merchant section should own implementation quickstarts.
The OpenDexter section should own public tool flow explanations.
The API and architecture section should own cross-system concepts like wallets, realtime, and connector OAuth.