x402 + Edge Compute: Paywalled Endpoints for Serverless and Workers

Quick Summary

Decision-makers can now easily add crypto-friendly, per-request pricing to any HTTP endpoint thanks to the x402 protocol. Plus, you can roll it out globally on edge runtimes like Cloudflare Workers, Vercel Functions (with Edge runtime), and Fastly Compute. In this post, we’ll dive into how to set up 402 → pay → retry paywalls in just a few minutes. We’ll also compare x402 with Lightning’s L402 and explore how to strengthen your setup for production using facilitator patterns, caching, observability, and security.

Why this matters now

For the first time ever, the HTTP 402 Payment Required status is getting some real action with the introduction of the x402 protocol. Here’s how it works: when a server sends back a 402, it includes specific payment details. The client pays on-chain and then tries again with an X-PAYMENT header. The server checks everything, settles the payment, and delivers the content.

Coinbase is keeping the open specification alive (Apache-2.0), complete with a facilitator API for verification and settlement, plus SDKs to make integration easier. The best part? It’s chain-agnostic and is already in use by various edge and agent platforms. Check it out here!

Edge compute makes paywalls feel almost immediate. With Workers and Edge Functions operating close to users, they provide low-latency headers and streams, plus they can handle settlement through background tasks. This is super important for monetizing APIs, data, or AI tools on a per-request basis. (workers.cloudflare.com)

x402 in one minute

Protocol: When servers run into a 402 error, they respond with a Payment Required message that includes details like the acceptable payment methods, the amount due, and some resource metadata. After clients make the payment, they resend their request with an X-PAYMENT header. The servers then verify and settle the payment, often including an X-PAYMENT-RESPONSE in their 200 OK reply. You can find more about this on GitHub.
Facilitator: This is an optional service that takes care of payment verification and settlement, which means your serverless app won’t have to deal with any blockchain code. Currently, Coinbase's facilitator offers free USDC settlement on Base, featuring handy /verify and /settle endpoints. Recent guidelines suggest that using /settle is generally more secure than /verify. Check out the details in the documentation.
Clients: To make handling 402 challenges and payment retries easier, clients can wrap the fetch function. There are various libraries available across different ecosystems, like x402-fetch, thirdweb, and Cloudflare Agents, which can simplify this process. More info is available at Cloudflare's developer documentation.

x402 is quite different from Lightning's L402 (previously known as LSAT). While L402 relies on 402 along with macaroons and Lightning invoices, it fuels production services through the Aperture proxy and handles both dynamic and fixed pricing at the proxy level. Both options activate HTTP 402, but they set themselves apart with their payment rails and token formats. Check out the details here.

Why edge runtimes are the right home for paywalled endpoints

Global, low-latency challenge/response. With this setup, workers and Edge Functions can quickly issue 402 responses, letting clients pay and then retry locally--no need for an origin roundtrip. Check it out here: (workers.cloudflare.com).
Streaming and background tasks. You can quickly send back a 200 response while handling non-critical tasks in the background, like logging or analytics, using waitUntil and tail handlers. Vercel Edge even supports streaming with a 25-second time-to-first-byte requirement and a 300-second streaming window. More details here: (developers.cloudflare.com).
Predictable costs. Vercel Edge bases its pricing on CPU execution units, while Cloudflare Workers charge for CPU time. Plus, Workers’ Durable Objects offer strong consistency for managing state related to receipts and credits right at the edge. Read more about it here: (vercel.com).

Architecture: 402 → pay → retry with a facilitator

So here’s the deal: the client kicks things off by sending a request to /premium. The server responds with a 402 status code and a JSON object that includes an “accepts” array. This array has info about the scheme/network, the maximum amount required, the resource, a description, and the MIME type. You can check out more about it on GitHub.
Once the client picks an option, they put together a Payment Payload, make the payment, and then resend their request with the X-PAYMENT header. You can get more details on this step on GitHub.
Now, the server needs to verify things, either using its local logic or by making a POST request to /verify through a facilitator. Ideally, in a production setup, it’s best to hold off until the /settle process is completed (or send a streamed/watermarked response while waiting for that settle response). For full guidance, take a look at the docs over at Coinbase.
Finally, the server comes back with a 200 status and includes the resource along with an optional X-PAYMENT-RESPONSE, which has the transaction hash and network details. You can dive deeper into this on GitHub.

MDN still has 402 marked as “reserved,” which is precisely what x402 standardizes. So, be prepared for some tools to view it as a little quirky unless you set up some specific handling for it. (developer.mozilla.org)

Implementation patterns on edge runtimes

1) Cloudflare Workers + Hono: 402 in 30 lines

Installing Middleware and Facilitator Client

To get started, you'll need to install both the middleware and the facilitator client. It's pretty straightforward:

Open your terminal.

Run the following command:

npm install your-middleware-package your-facilitator-client-package

Make sure to replace your-middleware-package and your-facilitator-client-package with the actual package names you're using.

Protecting Routes

Next up, let’s secure your routes. You want to ensure that only authorized users can access certain endpoints. Here’s a simple way to do it:

Import your middleware into your server file:

const { yourMiddleware } = require('your-middleware-package');

Then, use it in your route definitions like this:

app.use('/protected-route', yourMiddleware, (req, res) => {
    res.send('This is a protected route!');
});

This way, anyone trying to access /protected-route will have to go through your middleware first.

Persisting Receipts with Durable Objects

Finally, if you want to keep track of receipts, Durable Objects can be a lifesaver. Here’s how you can set it up:

Start by creating a Durable Object class for receipts:

class Receipt {
    constructor(state) {
        this.state = state;
    }
    async save(receiptData) {
        await this.state.storage.put('receipt', receiptData);
    }
    async fetch() {
        return await this.state.storage.get('receipt');
    }
}

Make sure to register your Durable Object in your application:

const RECEIPT_NAMESPACE = 'ReceiptNamespace';

export default {
    async fetch(request, env) {
        return env[RECEIPT_NAMESPACE].fetch(request);
    }
};

Now, you’re all set! You can save and retrieve receipts seamlessly with Durable Objects.

// wrangler.toml excerpts
compatibility_date = "2025-12-01"

[[durable_objects.bindings]]
name = "RECEIPTS"
class_name = "ReceiptsDO"

// src/worker.ts
import { Hono } from "hono";
import { paymentMiddleware } from "x402-hono";
import { waitUntil } from "cloudflare:workers";

type Env = {
  RECEIPTS: DurableObjectNamespace;
  // optional: FACILITATOR_URL, CDP_API_KEY_ID, CDP_API_KEY_SECRET
};

const app = new Hono<{ Bindings: Env }>();

// 1) Protect an endpoint with x402
app.use(
  "/reports/daily",
  paymentMiddleware("0xYourBaseUSDCAddress", {
    "/reports/daily": {
      price: "$0.05",
      network: "base", // or "base-sepolia" for test
      config: {
        description: "Daily premium report",
        mimeType: "application/json",
      },
    },
  })
);

// 2) Serve content and persist receipt after settlement
app.get("/reports/daily", async (c) => {
  const res = new Response(JSON.stringify({ ok: true, data: "..." }), {
    headers: { "Content-Type": "application/json" },
  });

  // Optional: settle out-of-band & persist (if your middleware only verified)
  const doId = c.env.RECEIPTS.idFromName("global");
  const stub = c.env.RECEIPTS.get(doId);
  const paymentHeader = c.req.header("x-payment") || "";
  waitUntil(stub.fetch("https://do/record", { method: "POST", body: paymentHeader }));

  return res;
});

export default {
  fetch: app.fetch,
};

// src/receipts.ts (Durable Object)
export class ReceiptsDO {
  state: DurableObjectState;
  constructor(state: DurableObjectState) { this.state = state; }
  async fetch(req: Request) {
    if (req.method === "POST") {
      const header = await req.text();
      await this.state.storage.put(`receipt:${Date.now()}`, header);
      return new Response("ok");
    }
    return new Response("not found", { status: 404 });
  }
}

Check out the Cloudflare Agents docs for a look at using paymentMiddleware (Hono) and wrapFetchWithPayment for smooth agent-to-endpoint interactions. These tools also work great in your Worker! (developers.cloudflare.com)
Don’t forget to use waitUntil for background persistence or settlement--this way, you can avoid blocking that 200 response. Cloudflare has made it super easy by allowing a direct import of waitUntil and even includes some examples of ctx.waitUntil. (developers.cloudflare.com)
If you’ve got long responses, consider streaming with ReadableStream after sending the headers. This helps keep your Time to First Byte (TTFB) nice and low. (developers.cloudflare.com)
And let’s not overlook Durable Objects--they offer globally consistent storage for your receipts and credits. Just keep in mind that there are free tier limits, so it's a good idea to plan your usage accordingly. (developers.cloudflare.com)

Security note: Make sure to upgrade to x402-hono version 0.5.2 or higher, as older versions have a vulnerability that’s been fixed. The latest stable versions are good to go with no known issues. Check it out here: (advisories.gitlab.com)

2) Vercel Functions (Edge runtime): manual x402 flow

Next.js Route Handler with Edge Runtime: Keeping Header Sizes in Check

When working with Next.js, especially using the Edge runtime, it's super important to manage your header sizes effectively. Large headers can lead to unexpected issues, like performance bottlenecks or even request failures. Let's dive into how to handle routes while keeping those headers nice and tidy.

Why Header Size Matters

Headers are a key part of HTTP requests and responses. They carry all sorts of info, including metadata, authentication tokens, and even content types. However, there's a limit to how big these headers can be. If they go beyond certain sizes, you might run into problems. Keeping headers small helps ensure your application runs smoothly, especially at the edge.

Setting Up a Route Handler

Here’s a simple way to create a route handler in your Next.js app that runs on the Edge:

export const config = {
  runtime: 'edge',
}

export default async function handler(req) {
  // Your logic goes here
  return new Response('Hello, Edge!', {
    headers: {
      'Content-Type': 'text/plain',
      'Cache-Control': 'max-age=3600',
    },
  })
}

In this example, we’re defining a route handler that responds with a basic message. Notice how we’re setting the Content-Type and Cache-Control headers - keeping it simple but efficient.

Tips for Keeping Header Sizes Down

Here are some handy tips for managing your header sizes while using the Edge runtime:

Use Short Keys and Values: Stick to concise names and values for your headers. This saves space and keeps things clear.
Limit the Number of Headers: Only send the headers that you absolutely need. Avoid sending unnecessary data.
Compress Data when Possible: If you can, compress values, especially for things like cookies or session tokens.
Monitor Your Sizes: Keep an eye on your headers during development. Tools like Postman or your browser's dev tools can be really helpful here.
Fallbacks and Defaults: If some headers aren’t critical, consider using defaults on the client-side to cut down on the number of headers sent.

Conclusion

Handling headers within size limits is crucial for a smooth experience in Next.js applications using the Edge runtime. By keeping headers small and relevant, you can enhance performance and reliability. So, be mindful of those headers as you build your Next.js routes!

// app/api/premium/route.ts
export const runtime = "edge";

const facilitatorUrl = "https://api.cdp.coinbase.com/v2/x402"; // example

export async function GET(req: Request) {
  const payment = req.headers.get("x-payment");

  // If no payment header → send 402 with payment requirements
  if (!payment) {
    const body = {
      x402Version: 1,
      accepts: [
        {
          scheme: "exact",
          network: "base",
          maxAmountRequired: "100000", // 0.1 USDC (6 decimals)
          resource: new URL(req.url).pathname,
          description: "Premium endpoint",
          mimeType: "application/json",
        },
      ],
    };
    return new Response(JSON.stringify(body), {
      status: 402,
      headers: { "Content-Type": "application/json", "Cache-Control": "no-store" },
    });
  }

  // Verify + settle (recommended) using facilitator
  const verify = await fetch(`${facilitatorUrl}/verify`, {
    method: "POST",
    headers: { "Content-Type": "application/json", /* add CDP auth if needed */ },
    body: JSON.stringify({
      x402Version: 1,
      paymentHeader: payment,
      paymentRequirements: {
        scheme: "exact",
        network: "base",
        maxAmountRequired: "100000",
        resource: "/api/premium",
        description: "Premium endpoint",
        mimeType: "application/json",
      },
    }),
  }).then((r) => r.json());

  if (!verify.isValid) {
    return new Response(JSON.stringify({ error: "invalid payment" }), { status: 402 });
  }

  const settle = await fetch(`${facilitatorUrl}/settle`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      x402Version: 1,
      paymentHeader: payment,
      paymentRequirements: {
        scheme: "exact",
        network: "base",
        maxAmountRequired: "100000",
        resource: "/api/premium",
        description: "Premium endpoint",
        mimeType: "application/json",
      },
    }),
  }).then((r) => r.json());

  if (!settle.success) return new Response("settlement failed", { status: 402 });

  return new Response(JSON.stringify({ premium: "ok" }), {
    headers: {
      "Content-Type": "application/json",
      "X-PAYMENT-RESPONSE": btoa(JSON.stringify(settle)),
      "Cache-Control": "private, no-store",
    },
  });
}

Just a heads up, Vercel's Edge runtime has some limits on request headers--you're allowed a max of 64 headers and about 16 KB total. Also, make sure to send that initial response within 25 seconds, though you can keep streaming for up to 300 seconds. It's a good idea to keep the X-PAYMENT compact and settle things quickly. Check out more details here.
When it comes to facilitator endpoints, you’ve got POST /verify and /settle to work with. Coinbase’s facilitator on Base is pretty cool because it offers fee-free USDC settlement (but just a heads up, that might change). It's generally better to go with /settle for a bit more security instead of just using /verify. If you want to dive deeper, here’s the link to the docs.

3) Fastly Compute@Edge: 402 challenge and header constraints

Fastly’s JavaScript runtime lets you create custom responses and headers, but keep an eye on those header count and size limits. For instance, you’ve got about 96 entries to play with in response headers, and you can't go over 128 KB. This is super important if you’re including hefty payment metadata in fields like 402 or X-PAYMENT-RESPONSE. Check out the details here.

// src/index.js (Fastly JS Compute)
import { Router } from "@fastly/expressly";

addEventListener("fetch", (event) => event.respondWith(app(event)));

async function app(event) {
  const req = event.request;
  const url = new URL(req.url);
  if (url.pathname === "/paid") {
    const xpay = req.headers.get("x-payment");
    if (!xpay) {
      const paymentBody = JSON.stringify({
        x402Version: 1,
        accepts: [{ scheme: "exact", network: "base", maxAmountRequired: "50000", resource: "/paid" }],
      });
      return new Response(paymentBody, {
        status: 402,
        headers: { "Content-Type": "application/json", "Cache-Control": "no-store" },
      });
    }
    // call facilitator /verify + /settle from here…
    return new Response(JSON.stringify({ ok: true }), { headers: { "Content-Type": "application/json" } });
  }
  return new Response("not found", { status: 404 });
}

Feel free to attach or tweak headers in Compute; just keep an eye on their size to prevent any overflow issues. (antoinebrossault.com)

4) AWS API Gateway + Lambda: it’s just HTTP

If your Lambda integration sends back a statusCode of 402, you can include a JSON body and custom headers, and the API Gateway will carry that through. There isn't a built-in x402 integration, so just handle it like any other 4xx status with your own specific meanings according to your documentation. MDN mentions that 402 is “reserved,” which is exactly why x402 helps clarify its use. (docs.aws.amazon.com)

Client tooling for agent and browser flows

Wrap fetch: With x402-fetch and cloud integrations, clients can automatically pay after a 402 challenge. If you're looking for some TypeScript examples, check out Cloudflare’s Agents docs. Plus, thirdweb has a cool fetch wrapper that works seamlessly with wallets and RPC infrastructure. You can find more details here.
Multi-runtime kits: There are packages available for Express, Hono, Next, and Axios. Just make sure to keep the core “x402” package pinned alongside its integration peers to ensure everything matches up nicely. You can explore it here.
Solana-first builders: Sol402 is great for setting up a pay-per-request proxy that settles USDC on Solana. It follows the same 402→pay→retry handshake (which is compatible with PayAI), making it a perfect fit for agentic traffic. Check it out here.

Choosing rails: x402 vs L402

So, x402 is pretty versatile and works across different blockchain networks. Right now, it’s all the rage with EVM USDC on Base, thanks to Coinbase’s facilitator, which is fee-free as noted in their docs. They're also branching out to Solana and looking into other setups like “upto” (basically, you can pay up to a certain amount for metered workloads). It defines the X-PAYMENT and X-PAYMENT-RESPONSE header formats along with some facilitator APIs. You can check out the details here: (docs.cdp.coinbase.com).
On the other hand, L402 (Lightning) is doing something cool by pairing macaroons with Lightning invoices through HTTP 402 challenges. The Aperture reverse proxy steps in to handle pricing and authentication for both gRPC and REST, which is actually used by production services like Loop/Pool. If you're into Bitcoin and Lightning, L402 is a solid choice with its surge and per-path pricing options. More info can be found here: (github.com).

Enterprises can operate simultaneously, like using an edge 402 router that provides x402 USDC on Base and L402 Lightning for BTC users. You can choose which one to use based on the Accepts list or your location. Check it out here: github.com

Pricing, latency, and UX tips

Keep the 402 body lightweight. On Vercel Edge, keep an eye on header counts and total header bytes; over on Fastly, there are strict limits on response header counts and sizes. Stick to concise descriptions and steer clear of heavy schemas in the 402 body. (vercel.com)
Stream whenever you can. Kick off the 200 response quickly and stream your content; Vercel Edge needs those headers sent out within 25 seconds, but you can keep the streaming going for up to 300 seconds. Cloudflare Workers’ streaming APIs help cut down on buffering and memory use. (vercel.com)
Cache rules: Just don’t cache 402 responses in shared caches; use Cache-Control: no-store. For paid responses, it's best to go with private, no-store or keyed caching tied to a short-lived receipt ID. Steer clear of Vary-on-cookie at CDNs; custom headers can work if you need them. (fastly.com)
Edge cost models: Vercel Edge charges based on CPU units; Workers charge for both CPU and Durable Object usage. Make sure to compare your per-request margin (like $0.01 USDC) with the average CPU time and settlement costs. (vercel.com)

Security and compliance guardrails

Verify, then settle--and it’s best to settle before you fulfill anything. The Coinbase team suggests not relying solely on /verify; treat your funds as committed only when /settle gives you the thumbs up. If you’re looking to cut down on TTFB, consider watermarking or limiting your output until the settlement wraps up. (github.com)
Pin SDK versions. There was a known issue with older x402-hono versions, so make sure you’re on version 0.5.2 or higher (the latest updates haven’t shown any issues). Keep an eye on packages like @coinbase/x402 for regular updates. (advisories.gitlab.com)
Observability: Make sure to log X-PAYMENT and X-PAYMENT-RESPONSE (just no secrets in there) and keep a tidy record (wallet, amount, txHash, network, resource) in Durable Objects or wherever you store your data.
Policy and attestations: Look out for optional facilitator-driven KYC/geo stuff and new payment flows (like subscriptions, top-ups, and “upto” metering) coming down the pipeline. It’s a good idea to plan for feature flags by region or segment. (x402.gitbook.io)

Chain selection: when to use which

Base (EVM) + USDC: This combo works really well for US audiences and fits right in with EVM ecosystems. Plus, with Coinbase handling the verify/settle process and offering zero-fee merchant settlement (as of this writing), it's a solid choice. It’s particularly handy for enterprise accounting since you’re dealing with a steady unit of account. Check it out here: (docs.cdp.coinbase.com).
Solana + USDC: With sub-second finality and fees that are practically nothing, this pairing opens the door for super aggressive micropayments and traffic-heavy applications. Sol402 even gives you a ready-to-use proxy builder that's compatible with PayAI flows--pretty neat! You can read more about it here: (solana.com).
Lightning (L402): If you’re all about Bitcoin and love the machine-to-machine Lightning ecosystems, this is definitely the way to go. Aperture has got your back with a comprehensive reverse proxy designed for metered APIs. Find out more on GitHub: (github.com).

Day 1

Choose an endpoint to work with, like /v1/summarize. Let's set the price at $0.01.
Deploy a Cloudflare Worker to manage things, and make sure to protect /v1/summarize with x402-hono. Don't forget to store the receipts in a Durable Object! Also, add strict no-store headers for both 402 and 200 responses. Check it out here: (developers.cloudflare.com)
Set up the facilitator on /settle and hold off on the response until everything goes through successfully. Keep that X-PAYMENT-RESPONSE handy for your records. You can find more info here: (docs.cdp.coinbase.com)

Day 2

Start integrating those client wrappers into your calling apps or agents (like x402-fetch or thirdweb) so that auto-pay kicks in.
Time for a load test! Make sure both the 402 and 200 paths are keeping it cool under the edge limits--think header sizes and first-byte SLAs. When you’re on Vercel, double-check that responses kick off in under 25 seconds. And for Workers, keep an eye on those streaming chunked responses and make sure you’re handling the waitUntil processing correctly. (vercel.com)
Let’s roll it out to about 5% of traffic and keep tabs on how the cost-per-paid-call stacks up against compute and facilitator latencies.

Beyond x402: L402 for Lightning-heavy users

If your users are all about Lightning, then L402 is a solid choice for you. It teams up with Aperture as a 402 reverse proxy for your gRPC/REST backends, which is pretty neat. You can set up pricing that’s either fixed or dynamic on a per-path basis, and thanks to macaroons, you can add some detailed restrictions (like per-method limits). Right now, several production services, like Loop and Pool, are already using it. It might be a good idea to offer both x402 and L402 to really grab those different market segments. Check it out on GitHub!

Emerging best practices (what we’re deploying for clients)

One paywall, many chains: Instead of sticking to just one option, advertise several “accepts” entries in the 402 response (like Base USDC and Solana USDC). This way, clients can choose the most cost-effective or quickest route. (github.com)
Async hardening: If you really need to send a response right after verification, consider streaming a partial response and only finish it when /settle is successful. If it doesn’t settle in N seconds, just time out and provide a simpler response instead. (vercel.com)
Keep headers lean: When serializing payment payloads, keep them compact so you don’t exceed Edge header limits (think Vercel header count/size and Fastly header size/count). (vercel.com)
No-store everywhere: Label your 402 and paid responses with no-store/private. This helps you dodge cache poisoning and stops paid content from leaking out. Instead of using cookies, use custom headers for vary logic at CDNs. (fastly.com)
Version pins and SBOM: Make sure to lock down your @coinbase/x402 and x402-hono versions, and keep an eye on any advisories (like GHSA-3j63-5h8p-gf7c). (advisories.gitlab.com)
Settlement-first policy: Always remember the motto “never trust verify” for any high-value content. Make sure you get a successful /settle before anything leaves the edge. (github.com)

The agent economy angle

Cloudflare Agents, along with several SDKs, are already set up to wrap fetch. This means autonomous agents can handle payments and retries all on their own. When it comes to Solana, turnkey builders like Sol402 are positioning x402 for super-fast, millisecond-grade agent loops using USDC. This setup is the foundation of what we’re calling “machine-commerce,” where bots are able to buy API calls and data without needing OAuth or any human intervention. (developers.cloudflare.com)

What to watch next

Protocol growth: We’re seeing some exciting new setups like the “upto” for metered or token-based workloads. Plus, we're getting Solana's "exact" scheme on par, along with support for EIP-4337 smart wallets. This means UserOperations can let smart accounts handle payments effortlessly. (x402.gitbook.io)
Neutral infrastructure: Think facilitator marketplaces and discovery layers, which are super handy. There’s also the option for attestations/KYC to help enterprises with their gating needs. (docs.cdp.coinbase.com)

Final take

x402 turns “pay-per-request” into a must-have web feature, and thanks to edge runtimes, it feels super fast. If you’re working with premium APIs, datasets, or inference, you can roll out a compliant paywall this week. Just return a 402 with x402 payloads, accept on-chain USDC, and handle verification and settlement through a facilitator--all while delivering from the edge. No need for accounts, cards, or complicated authentication!

Plus, when you combine this with L402 where Lightning is strong, you've got global coverage that’s smooth and hassle-free. Check it out here: (github.com)

7Block Labs offers some handy production templates for Cloudflare Workers, Vercel Edge, and Fastly (you can choose between x402 or L402). Plus, we’ve got features like observability, receipts, and billing exports all lined up for you. Whether you’re looking for a quick 48-hour pilot or planning a multi-region rollout with compliance and rate cards, just know we’ve got your back!

References and resources

Check out the x402 protocol specs and GitHub, along with headers and facilitator APIs. (github.com)
Dive into the x402 HTTP 402 concepts and the open Apache-2.0 documentation. (x402.gitbook.io)
Get the scoop on Coinbase's facilitator verify/settle and network support. (docs.cdp.coinbase.com)
Learn how to use x402 with Cloudflare Agents for Workers/agents. (developers.cloudflare.com)
Understand the edge runtime limits with Vercel (think headers and streaming windows). (vercel.com)
Get the lowdown on Fastly Compute header limits and how to construct responses. (docs.fastly.com)
Explore L402 (Lightning) and the Aperture proxy for those 402 paywalls. (github.com)
Check out Solana's x402 context and the Sol402 builder for USDC pay-per-request setups. (solana.com)
Take a look at MDN's background info on the reserved status of HTTP 402. (developer.mozilla.org)