Add x402 monetization - let AI agents pay per API call by sam00101011 · Pull Request #2699 · inkeep/agents

sam00101011 · 2026-03-15T10:30:52Z

What is this?

x402 is an open protocol that lets AI agents pay for API calls using the HTTP 402 status code. Instead of API keys and billing dashboards, agents pay per call in USDC on Base.

This PR adds the foundation for monetizing inkeep/agents's API endpoints. We found 9 endpoints in your README that agents could pay to access.

Why agents would pay for inkeep/agents

Each of these capabilities becomes a pay-per-call endpoint that AI agents discover and pay for automatically:

Visual drag-and-drop builder for rapid AI agent creation and management — agents pay per call instead of needing credentials or rate-limited free tiers
Two-way sync between code-based SDK and no-code visual interfaces — agents pay per call instead of needing credentials or rate-limited free tiers
Multi-agent architecture for complex, collaborative task automation — agents pay per call instead of needing credentials or rate-limited free tiers
Secure credential management for integrated MCP tools and services — agents pay per call instead of needing credentials or rate-limited free tiers
Observability suite with Traces UI and OpenTelemetry for agent monitoring — agents pay per call instead of needing credentials or rate-limited free tiers
Embeddable UI component library for dynamic, production-ready chat interfaces — agents pay per call instead of needing credentials or rate-limited free tiers

With x402, every feature above is instantly monetizable. Agents on Claude, Cursor, and any MCP client can discover and pay for access via 402.bot.

What's included

File	Purpose
`.well-known/x402.json`	Declares your endpoints, pricing, and wallet address - agents and routing networks use this for discovery
`x402-middleware-example.ts`	Drop-in middleware that returns `402` and verifies payments

How it works

Agent -> calls your API
     <- 402 Payment Required (price: $0.01, wallet, network)
Agent -> signs USDC payment on Base
     -> retries with x-payment header
     <- normal API response

Settlement is instant. No intermediary holds funds. Revenue goes directly to your wallet.

What you'd earn

~$1350/mo projected (9 endpoints x ~150 agent calls/mo x $0.01)

To activate

Replace YOUR_WALLET_ADDRESS in .well-known/x402.json with your Base wallet
Add the middleware to your server (see x402-middleware-example.ts)
Deploy - your API is now discoverable by every agent on the 402.bot routing network

Your endpoints will automatically appear in Claude, Cursor, and any MCP-compatible agent via the 402.bot MCP server.

Live demo

See how inkeep/agents works on the x402 network ->

Links

402.bot - routing oracle and provider marketplace
llms.txt - machine-readable service catalog
MCP setup guide
Provider registration

This PR was opened by 402.bot. x402 is an open protocol - you keep 100% of revenue. We just route agents to providers. If this isn't relevant, feel free to close.

changeset-bot · 2026-03-15T10:30:57Z

⚠️ No Changeset found

Latest commit: 299ac0d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

vercel · 2026-03-15T10:30:59Z

@sam00101011 is attempting to deploy a commit to the Inkeep Team on Vercel.

A member of the Team first needs to authorize it.

itoqa · 2026-03-15T11:09:10Z

Ito Test Report ❌

14 test cases ran. 3 passed, 11 failed.

🔍 Verification found a real application defect: the x402 discovery manifest is present in the repository but not exposed by the running API/UI route surface, so requests to /.well-known/x402.json return 404 instead of JSON. The failed checks are consistent manifestations of that same production-code integration gap.

✅ Passed (3)

Test Case	Summary	Timestamp
EDGE-1	Trailing-slash and duplicate-slash variants both returned controlled 308 redirects to the canonical manifest path with no unrelated content exposure.	2:20
ADV-1	POST/PUT/PATCH/DELETE returned controlled 404 responses and follow-up GET behavior remained unchanged after method probes.	5:10
ADV-2	Traversal probes produced controlled redirect/not-found responses and no .env or secret marker content was exposed.	5:10

❌ Failed (11)

Test Case	Summary	Timestamp
ROUTE-1	GET /.well-known/x402.json returned HTTP 404 instead of the discovery manifest payload.	0:00
ROUTE-2	Response content-type/body was HTML app shell instead of raw JSON for the manifest route.	0:00
LOGIC-1	Manifest schema validation failed because the route returned HTML/404 rather than parseable JSON.	0:00
LOGIC-2	Wallet readiness check could not execute because canonical manifest route returned 404 HTML.	0:49
RES-2	Resources semantic readiness check could not execute because canonical manifest route returned 404 HTML.	0:51
EDGE-2	Query variants were stable but all returned 404 HTML instead of manifest JSON.	2:20
EDGE-3	Deep-link refresh loop consistently returned 404 for the manifest route.	2:20
EDGE-4	Back-forward navigation remained stable but landed on 404 for manifest route.	2:20
EDGE-5	Mobile viewport access returned 404 HTML for manifest route instead of x402 JSON.	3:51
ADV-4	Parallel burst requests were consistent but consistently 404 for manifest route.	6:42
RES-1	Cross-origin probe hit 404 HTML on manifest route, so discovery response contract was not available.	7:09

Discovery manifest is reachable at expected path – Failed

Where: Public discovery endpoint /.well-known/x402.json.
Steps to reproduce: Request /.well-known/x402.json on the running app hosts.
What failed: The endpoint returns 404 (and often HTML shell) instead of the expected raw x402 JSON manifest.
Code analysis: The app mounts only workflow handlers under root /.well-known, while x402 manifest content exists as a repository file and is not routed/served at runtime.

Relevant code:

agents-api/src/createApp.ts (lines 260-270)

// management routes
app.route('/manage', manageRoutes);

// Mount execution routes - API key provides tenant, project, and agent context
app.route('/run', runRoutes);

// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

.well-known/x402.json (lines 1-12)

{
  "name": "inkeep/agents",
  "description": "Create AI Agents in a No-Code Visual Builder or TypeScript SDK with full 2-way sync. For shipping AI assistants and multi-agent AI workflows.",
  "accepts": [
    {
      "network": "eip155:8453",
      "asset": "USDC",
      "address": "YOUR_WALLET_ADDRESS"
    }
  ],
  "resources": []
}

Why this is likely a bug: Production routing does not expose the required manifest path even though manifest data was added, which directly causes endpoint unavailability.
Introduced by this PR: Yes – this PR modified the relevant code.

Raw JSON is served without HTML shell – Failed

Where: /.well-known/x402.json response format and content-type behavior.
Steps to reproduce: Fetch /.well-known/x402.json and inspect headers/body.
What failed: Response is HTML/not-found shell instead of application/json manifest payload.
Code analysis: No handler exists for x402 JSON at root well-known; only workflow routes are mounted there, so framework-level not-found HTML is returned on one host and plain 404 on the API host.

Relevant code:

agents-api/src/createApp.ts (lines 268-270)

// Mount eval workflow routes for internal workflow execution
// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

agents-api/src/domains/evals/workflow/routes.ts (lines 134-137)

workflowRoutes.post('/workflow/v1/flow', dispatchFlowOrStep);
workflowRoutes.post('/workflow/v1/step', dispatchFlowOrStep);

workflowRoutes.all('/workflow/v1/webhook/:token', async (c) => {

Why this is likely a bug: The manifest route is missing from production route definitions, so JSON delivery cannot occur.
Introduced by this PR: Yes – this PR modified the relevant code.

Manifest schema integrity check – Failed

Where: Manifest contract checks for required keys (name, description, accepts, resources).
Steps to reproduce: Load /.well-known/x402.json and attempt JSON parse/schema validation.
What failed: Schema checks cannot run because endpoint serves 404 content instead of manifest JSON.
Code analysis: Manifest JSON was added as a file, but app runtime does not map that file to the route under the serving package/app.

Relevant code:

.well-known/x402.json (lines 1-12)

{
  "name": "inkeep/agents",
  "description": "Create AI Agents in a No-Code Visual Builder or TypeScript SDK with full 2-way sync. For shipping AI assistants and multi-agent AI workflows.",
  "accepts": [
    {
      "network": "eip155:8453",
      "asset": "USDC",
      "address": "YOUR_WALLET_ADDRESS"
    }
  ],
  "resources": []
}

agents-api/src/createApp.ts (lines 268-270)

// Mount eval workflow routes for internal workflow execution
// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

Why this is likely a bug: The intended manifest schema cannot be consumed because the endpoint itself is not wired in runtime code.
Introduced by this PR: Yes – this PR modified the relevant code.

Production-readiness guard for wallet placeholder – Failed

Where: Manifest readiness validation for accepts[0].address.
Steps to reproduce: Fetch /.well-known/x402.json and inspect accepts[0].address.
What failed: Route returns 404 HTML, preventing readiness validation of wallet address.
Code analysis: The readiness check is blocked by missing route exposure, not by JSON field parsing logic.

Relevant code:

agents-api/src/createApp.ts (lines 268-270)

// Mount eval workflow routes for internal workflow execution
// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

.well-known/x402.json (lines 6-9)

    {
      "network": "eip155:8453",
      "asset": "USDC",
      "address": "YOUR_WALLET_ADDRESS"
    }

Why this is likely a bug: A production discovery contract cannot be validated when the canonical endpoint is unreachable due to missing route integration.
Introduced by this PR: Yes – this PR modified the relevant code.
Timestamp: 0:49

Manifest semantic readiness check for monetized resources – Failed

Where: Manifest resources semantic readiness checks.
Steps to reproduce: Fetch /.well-known/x402.json and inspect resources semantics.
What failed: Endpoint returns 404, so resource readiness semantics cannot be evaluated.
Code analysis: Root cause is the missing runtime mapping for /.well-known/x402.json in the app server.

Relevant code:

agents-api/src/createApp.ts (lines 268-270)

// Mount eval workflow routes for internal workflow execution
// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

.well-known/x402.json (lines 11-11)

  "resources": []

Why this is likely a bug: Expected manifest semantics are unreachable because the endpoint is not served.
Introduced by this PR: Yes – this PR modified the relevant code.
Timestamp: 0:51

Query-string stability and cache behavior – Failed

Where: Query variants of /.well-known/x402.json.
Steps to reproduce: Request canonical and query-variant manifest URLs (e.g., ?v=1, cache-bust values).
What failed: All variants return 404 HTML instead of a stable JSON manifest.
Code analysis: Since there is no x402 manifest route handler, query invariance tests only exercise not-found responses.

Relevant code:

agents-api/src/createApp.ts (lines 268-270)

// Mount eval workflow routes for internal workflow execution
// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

agents-api/src/domains/evals/workflow/routes.ts (lines 134-137)

workflowRoutes.post('/workflow/v1/flow', dispatchFlowOrStep);
workflowRoutes.post('/workflow/v1/step', dispatchFlowOrStep);

workflowRoutes.all('/workflow/v1/webhook/:token', async (c) => {

Why this is likely a bug: The intended discovery endpoint is absent, so query behavior is consistently incorrect for the feature.
Introduced by this PR: Yes – this PR modified the relevant code.
Timestamp: 2:20

Deep-link and refresh consistency – Failed

Where: Browser deep-link reload loop for /.well-known/x402.json.
Steps to reproduce: Open manifest URL directly and hard-refresh repeatedly.
What failed: Reloads are consistent but consistently return 404 content instead of manifest JSON.
Code analysis: The route itself is missing from runtime router wiring, so refresh stability cannot produce valid manifest content.

Relevant code:

agents-api/src/createApp.ts (lines 268-270)

// Mount eval workflow routes for internal workflow execution
// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

.well-known/x402.json (lines 1-12)

{
  "name": "inkeep/agents",
  "description": "Create AI Agents in a No-Code Visual Builder or TypeScript SDK with full 2-way sync. For shipping AI assistants and multi-agent AI workflows.",
  "accepts": [
    {
      "network": "eip155:8453",
      "asset": "USDC",
      "address": "YOUR_WALLET_ADDRESS"
    }
  ],
  "resources": []
}

Why this is likely a bug: Refresh behavior is not the defect; missing endpoint implementation is.
Introduced by this PR: Yes – this PR modified the relevant code.
Timestamp: 2:20

Back-forward navigation loop stability – Failed

Where: Browser history traversal from health page to manifest deep-link.
Steps to reproduce: Navigate health -> manifest -> back -> forward.
What failed: Forward returns 404 for manifest route instead of valid manifest JSON.
Code analysis: History behavior is stable; route is missing from runtime .well-known surface.

Relevant code:

agents-api/src/createApp.ts (lines 268-270)

// Mount eval workflow routes for internal workflow execution
// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

agents-api/src/domains/evals/workflow/routes.ts (lines 134-137)

workflowRoutes.post('/workflow/v1/flow', dispatchFlowOrStep);
workflowRoutes.post('/workflow/v1/step', dispatchFlowOrStep);

workflowRoutes.all('/workflow/v1/webhook/:token', async (c) => {

Why this is likely a bug: Expected manifest path is not implemented, so navigation loop cannot ever resolve valid content.
Introduced by this PR: Yes – this PR modified the relevant code.
Timestamp: 2:20

Mobile viewport manifest access – Failed

Where: Mobile viewport access to /.well-known/x402.json.
Steps to reproduce: Load canonical manifest URL in mobile emulation.
What failed: Route returns not-found HTML instead of x402 JSON.
Code analysis: The issue is route wiring/serving, so it reproduces regardless of viewport.

Relevant code:

agents-api/src/createApp.ts (lines 268-270)

// Mount eval workflow routes for internal workflow execution
// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

.well-known/x402.json (lines 1-12)

{
  "name": "inkeep/agents",
  "description": "Create AI Agents in a No-Code Visual Builder or TypeScript SDK with full 2-way sync. For shipping AI assistants and multi-agent AI workflows.",
  "accepts": [
    {
      "network": "eip155:8453",
      "asset": "USDC",
      "address": "YOUR_WALLET_ADDRESS"
    }
  ],
  "resources": []
}

Why this is likely a bug: Viewport-independent 404 behavior indicates missing endpoint implementation rather than a responsive UI issue.
Introduced by this PR: Yes – this PR modified the relevant code.
Timestamp: 3:51

Rapid parallel fetch burst consistency – Failed

Where: Concurrent requests to /.well-known/x402.json.
Steps to reproduce: Send parallel bursts (e.g., 30 GETs) to canonical manifest path.
What failed: Responses are consistently 404, not valid discovery JSON.
Code analysis: Concurrency is stable, but endpoint implementation is absent from app router so every request fails uniformly.

Relevant code:

agents-api/src/createApp.ts (lines 268-270)

// Mount eval workflow routes for internal workflow execution
// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

agents-api/src/domains/evals/workflow/routes.ts (lines 134-137)

workflowRoutes.post('/workflow/v1/flow', dispatchFlowOrStep);
workflowRoutes.post('/workflow/v1/step', dispatchFlowOrStep);

workflowRoutes.all('/workflow/v1/webhook/:token', async (c) => {

Why this is likely a bug: The route contract is missing, so high-load behavior can only return not-found.
Introduced by this PR: Yes – this PR modified the relevant code.
Timestamp: 6:42

Cross-origin fetch viability for agent clients – Failed

Where: Cross-origin probe against manifest discovery path.
Steps to reproduce: Request /.well-known/x402.json with an Origin header.
What failed: Request returns 404 HTML payload rather than valid manifest JSON for client discovery.
Code analysis: Cross-origin viability cannot be validated because the underlying manifest endpoint is not implemented in serving routes.

Relevant code:

agents-api/src/createApp.ts (lines 268-270)

// Mount eval workflow routes for internal workflow execution
// Mount at /.well-known - routes inside define /workflow/v1/flow etc.
app.route('/.well-known', workflowRoutes);

.well-known/x402.json (lines 1-12)

{
  "name": "inkeep/agents",
  "description": "Create AI Agents in a No-Code Visual Builder or TypeScript SDK with full 2-way sync. For shipping AI assistants and multi-agent AI workflows.",
  "accepts": [
    {
      "network": "eip155:8453",
      "asset": "USDC",
      "address": "YOUR_WALLET_ADDRESS"
    }
  ],
  "resources": []
}

Why this is likely a bug: Discovery clients cannot use the feature until the manifest route is actually served.
Introduced by this PR: Yes – this PR modified the relevant code.
Timestamp: 7:09

📋 View Recording

Screen Recording

Add x402 monetization (/.well-known/x402.json + middleware)

299ac0d

itoqa bot mentioned this pull request Mar 16, 2026

ci: provision PR preview environments #2681

Open

amikofalvy closed this Mar 16, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add x402 monetization - let AI agents pay per API call#2699

Add x402 monetization - let AI agents pay per API call#2699
sam00101011 wants to merge 1 commit intoinkeep:mainfrom
sam00101011:add-x402-monetization

sam00101011 commented Mar 15, 2026 •

edited

Loading

Uh oh!

changeset-bot bot commented Mar 15, 2026

Uh oh!

vercel bot commented Mar 15, 2026

Uh oh!

itoqa bot commented Mar 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

sam00101011 commented Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is this?

Why agents would pay for inkeep/agents

What's included

How it works

What you'd earn

To activate

Live demo

Links

Uh oh!

changeset-bot bot commented Mar 15, 2026

⚠️ No Changeset found

Uh oh!

vercel bot commented Mar 15, 2026

Uh oh!

itoqa bot commented Mar 15, 2026

Ito Test Report ❌

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

sam00101011 commented Mar 15, 2026 •

edited

Loading