{ "slug": "measuring-agent-revenue", "title": "Measuring Revenue from AI Agent Traffic: Beyond the Traffic Log", "description": "The revenue-layer fields and queries a seller adds on top of a general traffic log — authorized-vs-settled, revenue per rail, revenue per tier, and how to avoid double-counting a webhook retry as two sales.", "kind": "sub", "order": 12, "target_query": "measuring revenue from AI agent traffic", "secondary_queries": [ "how to track revenue from AI agent purchases", "x402 settlement vs authorization for revenue reporting", "avoiding double counted revenue from Stripe webhook retries", "revenue per payment rail for agent sales" ], "tags": [ "analytics", "revenue", "measurement", "x402", "payments", "agents", "monetization" ], "published": "2026-08-05", "updated": "2026-08-05", "words": 1636, "premium": false, "license": "https://changegamer.ai/license.xml", "canonical": "https://changegamer.ai/articles/measuring-agent-revenue", "markdown": "https://changegamer.ai/articles/measuring-agent-revenue.md", "takeaways": [ "A `payment_required` or `upgrade` row in a traffic log is a signal of interest, not revenue — revenue exists only once a payment is actually settled, which for the key rail means a webhook-triggered mint and for x402 means an `X-PAYMENT-RESPONSE` settlement receipt, not the initial 402 or the initial `X-PAYMENT` retry.", "A revenue log needs at least four fields a general traffic log does not carry: a unique settlement or session id, the rail used, the tier or price actually charged, and a settled/authorized status — without the id, a Stripe webhook retry gets counted as a second sale.", "On ChangeGamer today, only one of its three rails has any measured revenue at all: the Stripe key-sale rail is live, native x402 returns HTTP 503 and settles nothing, and the RSL crawl-license rate is declared but not collected — so a revenue query grouped by rail should show two rows at zero no matter what the underlying traffic log says.", "The RSL declared rate (US$0.05 per crawl) and the 402 JSON body's `price_usd` field (also \"0.05\") are different numbers in different number spaces that happen to share a digit — a revenue query that sums them as one figure is wrong by construction, not just imprecise.", "The `upgrade` outcome — a valid key of insufficient tier hitting the paywall again — is the cleanest observable repeat-interest signal in the log, and counting it over time is a legitimate starting point for a revenue-over-time view even before enough purchases exist to compute anything resembling lifetime value." ], "outline": [ { "depth": 2, "text": "Start from the traffic schema, add the revenue fields", "anchor": "start-from-the-traffic-schema-add-the-revenue-fields", "url": "https://changegamer.ai/articles/measuring-agent-revenue#start-from-the-traffic-schema-add-the-revenue-fields" }, { "depth": 2, "text": "Authorized is not settled", "anchor": "authorized-is-not-settled", "url": "https://changegamer.ai/articles/measuring-agent-revenue#authorized-is-not-settled" }, { "depth": 2, "text": "Revenue per rail: reconcile against what is actually live", "anchor": "revenue-per-rail-reconcile-against-what-is-actually-live", "url": "https://changegamer.ai/articles/measuring-agent-revenue#revenue-per-rail-reconcile-against-what-is-actually-live" }, { "depth": 2, "text": "Revenue per tier, and the conversion funnel from wall to sale", "anchor": "revenue-per-tier-and-the-conversion-funnel-from-wall-to-sale", "url": "https://changegamer.ai/articles/measuring-agent-revenue#revenue-per-tier-and-the-conversion-funnel-from-wall-to-sale" }, { "depth": 2, "text": "Avoiding a double-counted sale", "anchor": "avoiding-a-double-counted-sale", "url": "https://changegamer.ai/articles/measuring-agent-revenue#avoiding-a-double-counted-sale" }, { "depth": 2, "text": "Repeat-buyer signal as a starting point, not a computed LTV", "anchor": "repeat-buyer-signal-as-a-starting-point-not-a-computed-ltv", "url": "https://changegamer.ai/articles/measuring-agent-revenue#repeat-buyer-signal-as-a-starting-point-not-a-computed-ltv" }, { "depth": 2, "text": "What this actually looks like right now", "anchor": "what-this-actually-looks-like-right-now", "url": "https://changegamer.ai/articles/measuring-agent-revenue#what-this-actually-looks-like-right-now" } ], "faq": [ { "question": "Is a 402 response counted as revenue?", "answer": "No. A `402 Payment Required` response, and the `payment_required` outcome it produces in a traffic log, only records that a wall was hit — it says nothing about whether anyone paid. The same is true one step further along the funnel: on the native x402 rail, the initial `X-PAYMENT` retry is a signed authorization, not settled funds. Revenue exists only at the point a payment actually settles — a Stripe webhook firing and a key being minted, or an `X-PAYMENT-RESPONSE` settlement receipt coming back from a facilitator. Counting anything upstream of those events as revenue overstates it." }, { "question": "Why would a revenue log double-count a single sale?", "answer": "Because Stripe retries webhook delivery, and a log keyed only on \"a webhook arrived\" counts each delivery as a separate event. [How to sell to AI agents](/articles/selling-to-ai-agents) already documents the fix on the minting side — idempotent key minting keyed to the checkout session, so a retried webhook does not mint a second key. The measurement-side consequence is the same discipline applied to the revenue row itself: key it on the unique settlement or session id, not on webhook-received-count, so a retried delivery updates or ignores an existing row instead of inserting a new one." }, { "question": "How much has ChangeGamer actually earned from agent traffic, measured this way?", "answer": "Thin, and it says so plainly rather than implying otherwise. As of August 2026 the Stripe-backed key rail is the only one with any settled revenue at all; native x402 is scaffolded but dormant (`/api/x402/` returns HTTP 503, so it settles nothing regardless of how much interest the traffic log shows), and the RSL crawl-license rate is declared but not yet collected, pending RSL Collective registration. A revenue query grouped by rail on this site today would correctly show two of three rows at zero." }, { "question": "Is the RSL $0.05-per-crawl rate the same number as the price_usd field in the 402 response?", "answer": "No, and conflating them is a specific, easy-to-make measurement mistake. The RSL declared rate is a passive, per-crawl licensing price for AI-training use, published at `/license.xml` and not yet being collected. The `price_usd` field in the 402 JSON body is an unrelated per-fetch accounting figure the worker attaches to the Bearer-key gate; the actual key purchase price is in EUR (a €5.00 Starter key), not USD. Both happen to read \"0.05\" today, but they measure different things on different rails — do not sum them or use one as a check on the other." } ], "body": "A traffic log tells you who showed up at the wall. It does not tell you who paid, how much, on which rail, or whether that number is even real revenue yet — that is a layer on top, and this article is that layer. It sits inside [how to sell to AI agents](/articles/selling-to-ai-agents), the pillar for this cluster, as the last piece: the pillar's own \"An honest ledger\" section already states which of its three rails carry real revenue today, and this article is about how to measure that correctly rather than assume it.\n\n## Start from the traffic schema, add the revenue fields\n\nThe base row schema — `timestamp`, `path`, `user_agent`, `status`, `outcome`, `verified` — and the five general diagnostic queries built on it belong to [measuring AI agent traffic](/articles/measuring-ai-agent-traffic); this article does not repeat that schema or those queries. What a revenue question needs on top of it is a second, narrower table (or a set of additional fields on the same row, if your log store makes that easy) that only exists for rows where `outcome` is `served_paid`, `payment_required`, or `upgrade`:\n\n| Field | Example | Why it is not in the base schema |\n|---|---|---|\n| `settlement_id` | Stripe checkout session id, or x402 settlement receipt id | The unique key a revenue row is deduplicated on — see the double-counting section below |\n| `rail` | `stripe_key`, `x402`, `rsl_crawl` | Revenue has to be attributable to a rail before it can be reconciled against that rail's actual state |\n| `tier` | `starter`, `corpus`, `enterprise`, `corpus_annual` | Needed for any revenue-per-tier view; not meaningful for x402 or RSL, which are not tiered |\n| `amount` and `currency` | `5.00` / `EUR` | The traffic log's `outcome` field says *that* a wall was hit; it does not carry *how much* |\n| `settled` | `true` / `false` | The authorized-vs-settled distinction below — this is the field that turns a signal into a revenue fact |\n\nNone of this replaces the base traffic log; it is a narrower table joined to it by path and timestamp, populated only at the payment steps. Logging these fields on every request would be wasted effort — most rows never reach a payment step at all.\n\n## Authorized is not settled\n\nA payment row only becomes revenue once it is settled, and the gap between authorized and settled is the single most common way a revenue count is inflated. On the Bearer-key rail, the event that matters is the Stripe webhook actually firing and a key actually being minted — not the buyer landing on the checkout page. On native x402, the boundary is sharper and better documented: the client signs a stablecoin transfer authorization locally and retries with an `X-PAYMENT` header, but that is only an authorized intent to pay; the payment becomes real when a facilitator verifies and settles it on-chain and returns an `X-PAYMENT-RESPONSE` settlement receipt, per [agent wallets and x402](/resources/agent-wallets-x402). A revenue query that counts `X-PAYMENT` retries instead of settlement receipts is counting attempts, not sales.\n\nThis distinction also explains why a settled x402 payment cannot simply be subtracted back out if something goes wrong downstream. [Refunds and disputes with agent buyers](/articles/refunds-and-disputes-with-agent-buyers) documents that a settled x402 payment has no seller-side reversal mechanism in this corpus — settlement is effectively final. That is a reason to get the settled/authorized distinction right at measurement time rather than planning to correct it later: once a row is counted as settled revenue on that rail, there is no documented \"unsettle\" step to run if it turns out to be wrong.\n\n## Revenue per rail: reconcile against what is actually live\n\nA revenue-per-rail query only means something if it is checked against each rail's real operating state, and on ChangeGamer as of August 2026 those three states are very different from each other:\n\n| Rail | Revenue-measurement state |\n|---|---|\n| Stripe key sales (Starter €5, Corpus €25, Enterprise €150, Corpus Updates €45/yr) | **Live** — this is where measured revenue actually exists; every settled webhook is a real sale |\n| Native x402 (`/api/x402/`) | **Scaffolded, dormant** — the endpoint returns HTTP 503, so no `X-PAYMENT-RESPONSE` is ever produced; a revenue query for this rail should return zero, regardless of how many `payment_required` rows the traffic log shows against x402 paths |\n| RSL crawl-license (`/license.xml`, declared US$0.05/crawl) | **Declared, not collected** — RSL Collective registration is pending, so no crawl-license revenue is being collected against the declared rate; a revenue query for this rail should also return zero |\n\nThe practical rule that follows: a `GROUP BY rail` revenue query should show two of its three rows at exactly zero right now, and a nonzero value on either of those two rows is a bug in the measurement pipeline, not good news. It is tempting to read a spike of `payment_required` outcomes against an x402 path as \"x402 revenue is picking up\" — it is not revenue at all until settlement is switched on server-side, however much interest the traffic log shows upstream of that.\n\nThe other reconciliation trap sits inside the numbers themselves. The RSL declared rate is US$0.05 per crawl for `ai-all` usage — a passive, per-crawl licensing figure that is not currently being collected. The 402 JSON body's `price_usd` field is a different number in a different space: a per-fetch accounting figure the worker attaches to premium-slug responses, unrelated to the RSL rate and unrelated to the €5.00 EUR price a Starter key actually costs. Both happen to read `\"0.05\"` today. A revenue query that adds them, or that uses one to sanity-check the other, is combining two unrelated numbers that happen to share a digit — state this explicitly in any dashboard or note that surfaces both figures, so a future reader does not \"reconcile\" them into a single, wrong total.\n\n## Revenue per tier, and the conversion funnel from wall to sale\n\nFor the one rail that is actually live, revenue per tier is a straightforward `GROUP BY tier, SUM(amount)` over settled rows — the tier structure and what differs between ChangeGamer's four tiers is covered in [pricing tiers for machine buyers](/articles/pricing-tiers-for-machine-buyers) and is not re-derived here. The more diagnostic query sits one step earlier: the conversion rate from `payment_required` to `served_paid` for a given path or tier, computed as `COUNT(served_paid) / COUNT(payment_required)` over the same window. A wide gap between the two — many wall hits, few settled sales — points at the same three causes the pillar names for zero revenue generally: the price sits above a buyer's spend ceiling, the checkout step has a human-only friction point an agent cannot clear, or the traffic hitting the wall was never commercial in the first place. A `payment_required`-to-`served_paid` query does not tell you which of those three it is, but it tells you there is a gap worth investigating, which a settled-revenue total alone does not surface.\n\n## Avoiding a double-counted sale\n\nA revenue row keyed only on \"a webhook was received\" will overcount, because Stripe retries webhook delivery on transient failures and a naive counter treats each delivery as a new event. [How to sell to AI agents](/articles/selling-to-ai-agents) already documents the fix on the minting side — idempotent key minting, guarded by the checkout session id, so a retried webhook does not mint a second key for the same purchase — and that mechanism is not repeated here. The measurement-side consequence is a parallel discipline applied to the revenue row itself, not the key: a revenue table needs a unique constraint on `settlement_id` (the Stripe session id, or the x402 settlement receipt id), with a retried webhook delivery updating or being ignored against the existing row rather than inserting a new one. A revenue dashboard summing `COUNT(*)` over raw webhook-received log lines, instead of `COUNT(DISTINCT settlement_id)`, will silently report more sales than actually happened — and the error only shows up as a discrepancy against the transaction count in the Stripe dashboard itself, which is a bad place to first notice it.\n\n## Repeat-buyer signal as a starting point, not a computed LTV\n\nThe cleanest observable repeat-interest signal in the log is the `upgrade` outcome — a valid key of insufficient tier hitting the paywall again — because it can only fire for a caller who has already paid once. Counting `upgrade` events per identifier over a rolling window is a reasonable starting point for a revenue-over-time or cohort view: a rising count of repeat `upgrade` hits from the same key population is a legitimate early signal that a customer base is forming, even before there is enough purchase history to compute anything resembling a real lifetime-value figure. Resist the temptation to convert an early `upgrade` count into a specific LTV number — with a small, new corpus and a wall this recent, that number would be manufactured precision, not measurement. The honest version of this metric today is a count and a trend line, not a dollar figure.\n\n## What this actually looks like right now\n\nA guide about revenue measurement should be honest about the revenue it is measuring. On ChangeGamer as of August 2026, the correct output of everything above is not a mature revenue dashboard — it is a small number of settled Stripe transactions, two rails correctly reporting zero, and a repeat-buyer count too small yet to plot a meaningful trend. That is not a failure of the measurement approach; it is what measuring correctly, from day one, on a rail that has almost no revenue yet actually looks like. The value of building the settlement-keyed, rail-attributed schema now is that it produces a trustworthy number the day volume shows up, instead of a retroactive cleanup project once a webhook-retry bug or a rail-conflation error has already inflated months of history.", "cluster": { "id": "selling-to-agents", "title": "Selling to AI agents", "description": "How to sell content, APIs and tools to buyers that are software — discovery, machine-readable offers, spend ceilings, payment rails, and what breaks.", "status": "complete", "pillar": { "slug": "selling-to-ai-agents", "title": "How to Sell to AI Agents: The Complete Guide to Machine Buyers", "description": "The operator playbook for selling content, APIs and tools to buyers that are software: how agents discover, evaluate, authorize and pay — and the four rails you can charge them on today.", "kind": "pillar", "order": 0, "html": "https://changegamer.ai/articles/selling-to-ai-agents", "markdown": "https://changegamer.ai/articles/selling-to-ai-agents.md", "json": "https://changegamer.ai/api/articles/selling-to-ai-agents.json" }, "articles": [ { "slug": "agent-checkout-vs-human-checkout", "title": "Agent Checkout vs. Human Checkout: Why Your Payment Flow Fails Machine Buyers", "description": "Why checkout built for a person watching a screen is unusable by an AI agent, and what a checkout flow that actually completes for a machine buyer looks like — 402 + API key versus native x402.", "kind": "sub", "order": 1, "html": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout", "markdown": "https://changegamer.ai/articles/agent-checkout-vs-human-checkout.md", "json": "https://changegamer.ai/api/articles/agent-checkout-vs-human-checkout.json" }, { "slug": "machine-readable-pricing-pages", "title": "Machine-Readable Pricing Pages: How to Let an Agent Evaluate Your Offer Before It Pays", "description": "Why a prose pricing page cannot be evaluated by an AI agent, what fields a machine-readable offer catalog needs, and how to keep it in lockstep with your human pricing page and your 402 body.", "kind": "sub", "order": 2, "html": "https://changegamer.ai/articles/machine-readable-pricing-pages", "markdown": "https://changegamer.ai/articles/machine-readable-pricing-pages.md", "json": "https://changegamer.ai/api/articles/machine-readable-pricing-pages.json" }, { "slug": "acp-vs-ap2-vs-x402", "title": "ACP vs. AP2 vs. x402: Which Agent Payment Rail Should You Implement?", "description": "A decision framework for choosing between ACP, AP2, and x402 (plus the self-hosted 402 gate) — sorted by who your buyer actually is, what you are selling, and what is live versus waitlisted today.", "kind": "sub", "order": 3, "html": "https://changegamer.ai/articles/acp-vs-ap2-vs-x402", "markdown": "https://changegamer.ai/articles/acp-vs-ap2-vs-x402.md", "json": "https://changegamer.ai/api/articles/acp-vs-ap2-vs-x402.json" }, { "slug": "accepting-x402-payments", "title": "How to Accept x402 Stablecoin Payments: A Seller Implementation Guide", "description": "A build guide for sellers who have already decided x402 is the right rail: the 402 response shape, the wallet/facilitator/network choices, the verify-then-settle retry flow, exact vs. upto pricing, and how to ship it dormant until you are ready to go live.", "kind": "sub", "order": 4, "html": "https://changegamer.ai/articles/accepting-x402-payments", "markdown": "https://changegamer.ai/articles/accepting-x402-payments.md", "json": "https://changegamer.ai/api/articles/accepting-x402-payments.json" }, { "slug": "api-key-issuance-for-agents", "title": "Issuing API Keys to AI Agents Automatically: A Build Guide", "description": "How to design a system that mints and delivers API keys to agent and software buyers with minimal human friction: trigger models, storage, delivery, key format, tiering, rotation and revocation — illustrated with ChangeGamer's own Stripe-webhook mechanism.", "kind": "sub", "order": 5, "html": "https://changegamer.ai/articles/api-key-issuance-for-agents", "markdown": "https://changegamer.ai/articles/api-key-issuance-for-agents.md", "json": "https://changegamer.ai/api/articles/api-key-issuance-for-agents.json" }, { "slug": "pricing-tiers-for-machine-buyers", "title": "Pricing Tiers for API and Corpus Access: What Actually Varies Between Them", "description": "The axes that actually distinguish one pricing tier from another for a machine buyer — rate limits, content scope, deliverables and license grant — and how ChangeGamer structures its own four tiers around deliverable and license, not gated content.", "kind": "sub", "order": 6, "html": "https://changegamer.ai/articles/pricing-tiers-for-machine-buyers", "markdown": "https://changegamer.ai/articles/pricing-tiers-for-machine-buyers.md", "json": "https://changegamer.ai/api/articles/pricing-tiers-for-machine-buyers.json" }, { "slug": "agent-spend-limits-and-trust", "title": "Agent Spend Limits and Trust: What a Seller Should Verify Before Granting Access", "description": "The seller-side counterpart to agent spend controls — how an API operator reads an inbound agent's spend ceiling before granting access, which payment protocols actually prove that ceiling, how to revoke access, and what \"trust\" operationally means for a seller when no portable agent-reputation standard exists yet.", "kind": "sub", "order": 7, "html": "https://changegamer.ai/articles/agent-spend-limits-and-trust", "markdown": "https://changegamer.ai/articles/agent-spend-limits-and-trust.md", "json": "https://changegamer.ai/api/articles/agent-spend-limits-and-trust.json" }, { "slug": "refunds-and-disputes-with-agent-buyers", "title": "Refunds and Disputes with Agent Buyers: What a Seller Actually Does", "description": "What happens on the seller side when an autonomous agent's purchase needs to be reversed or is disputed — API-key refund mechanics, why x402 settlement cannot be undone, what card-token revocation does and does not prove, and what to log before you reverse anything.", "kind": "sub", "order": 8, "html": "https://changegamer.ai/articles/refunds-and-disputes-with-agent-buyers", "markdown": "https://changegamer.ai/articles/refunds-and-disputes-with-agent-buyers.md", "json": "https://changegamer.ai/api/articles/refunds-and-disputes-with-agent-buyers.json" }, { "slug": "packaging-a-corpus-as-a-product", "title": "Packaging a Corpus as a Product: Format, Schema, Versioning and Delivery", "description": "The packaging decisions behind selling a content corpus as a dataset product — export format, the free-sample/gated-full split, a per-record metadata schema, a corpus version number, and which of three delivery mechanisms to use — grounded in ChangeGamer's own three real export formats.", "kind": "sub", "order": 9, "html": "https://changegamer.ai/articles/packaging-a-corpus-as-a-product", "markdown": "https://changegamer.ai/articles/packaging-a-corpus-as-a-product.md", "json": "https://changegamer.ai/api/articles/packaging-a-corpus-as-a-product.json" }, { "slug": "discoverability-for-paid-agent-apis", "title": "How Do AI Agents Discover Paid APIs? A Guide to Every Surface", "description": "How an AI agent finds out a paid API or resource exists before it ever reads a price: llms.txt, the JSON API index, MCP registries, incidental 402 discovery, x402 auto-listing, and what .well-known does and does not cover.", "kind": "sub", "order": 10, "html": "https://changegamer.ai/articles/discoverability-for-paid-agent-apis", "markdown": "https://changegamer.ai/articles/discoverability-for-paid-agent-apis.md", "json": "https://changegamer.ai/api/articles/discoverability-for-paid-agent-apis.json" }, { "slug": "fraud-and-abuse-from-agent-traffic", "title": "Fraud and Abuse from AI Agent Traffic: What a Seller Should Detect", "description": "How a seller of APIs, content, or tools to AI agents spots and mitigates abuse once access is already granted — key sharing, over-scope scraping, spend-ceiling circumvention, spoofed identity, and rate-limit evasion patterns specific to autonomous agents.", "kind": "sub", "order": 11, "html": "https://changegamer.ai/articles/fraud-and-abuse-from-agent-traffic", "markdown": "https://changegamer.ai/articles/fraud-and-abuse-from-agent-traffic.md", "json": "https://changegamer.ai/api/articles/fraud-and-abuse-from-agent-traffic.json" }, { "slug": "measuring-agent-revenue", "title": "Measuring Revenue from AI Agent Traffic: Beyond the Traffic Log", "description": "The revenue-layer fields and queries a seller adds on top of a general traffic log — authorized-vs-settled, revenue per rail, revenue per tier, and how to avoid double-counting a webhook retry as two sales.", "kind": "sub", "order": 12, "html": "https://changegamer.ai/articles/measuring-agent-revenue", "markdown": "https://changegamer.ai/articles/measuring-agent-revenue.md", "json": "https://changegamer.ai/api/articles/measuring-agent-revenue.json" } ] }, "navigation": { "pillar": { "slug": "selling-to-ai-agents", "title": "How to Sell to AI Agents: The Complete Guide to Machine Buyers", "description": "The operator playbook for selling content, APIs and tools to buyers that are software: how agents discover, evaluate, authorize and pay — and the four rails you can charge them on today.", "kind": "pillar", "order": 0, "html": "https://changegamer.ai/articles/selling-to-ai-agents", "markdown": "https://changegamer.ai/articles/selling-to-ai-agents.md", "json": "https://changegamer.ai/api/articles/selling-to-ai-agents.json" }, "previous": { "slug": "fraud-and-abuse-from-agent-traffic", "title": "Fraud and Abuse from AI Agent Traffic: What a Seller Should Detect", "description": "How a seller of APIs, content, or tools to AI agents spots and mitigates abuse once access is already granted — key sharing, over-scope scraping, spend-ceiling circumvention, spoofed identity, and rate-limit evasion patterns specific to autonomous agents.", "kind": "sub", "order": 11, "html": "https://changegamer.ai/articles/fraud-and-abuse-from-agent-traffic", "markdown": "https://changegamer.ai/articles/fraud-and-abuse-from-agent-traffic.md", "json": "https://changegamer.ai/api/articles/fraud-and-abuse-from-agent-traffic.json" }, "next": null }, "resources": [ { "slug": "access-and-pricing", "html": "https://changegamer.ai/resources/access-and-pricing", "markdown": "https://changegamer.ai/resources/access-and-pricing.md", "json": "https://changegamer.ai/api/resources/access-and-pricing.json" }, { "slug": "paying-for-access-402", "html": "https://changegamer.ai/resources/paying-for-access-402", "markdown": "https://changegamer.ai/resources/paying-for-access-402.md", "json": "https://changegamer.ai/api/resources/paying-for-access-402.json" }, { "slug": "agent-wallets-x402", "html": "https://changegamer.ai/resources/agent-wallets-x402", "markdown": "https://changegamer.ai/resources/agent-wallets-x402.md", "json": "https://changegamer.ai/api/resources/agent-wallets-x402.json" }, { "slug": "selling-to-agents", "html": "https://changegamer.ai/resources/selling-to-agents", "markdown": "https://changegamer.ai/resources/selling-to-agents.md", "json": "https://changegamer.ai/api/resources/selling-to-agents.json" } ] }