Performance and reliability

The short answer: Forge runs inside your server, but it makes no network calls while your API serves a request, adds a few microseconds, never touches payment verification or settlement, and fails open. If the Forge backend is down, or Forge is misconfigured, your API and payments work exactly as they did without it.

The critical path

Your critical path is everything a request has to go through before the caller gets a response. Anything on it adds latency to every request, and if it fails, requests fail.

Step of a paid request	Who does it	Forge involved?
Return the 402 challenge	Your x402 middleware	Adds the sentence and extension to the header, in memory (~4 µs)
Verify the payment	Your x402 middleware + facilitator	No
Run your handler	You	No
Settle the payment	Your x402 middleware + facilitator	No
Send the response	Your framework	Adds the feedback ID to the body and headers, in memory (~3.4 µs)
Report the call	Forge, in the background	Queued in memory, sent in batches every 2 s, after the response

Requests to routes that aren’t paid pass through in about 0.06 µs.

Measured on an Apple M3 Pro with Node 22, @forgeintel/sdk 0.3 and a typical weather-API response. Feedback IDs are generated locally with an HMAC, so there’s no lookup, database or network call per request.

When something goes wrong

What happens	Your API	Payments	Ratings
The Forge backend is down or slow	Unchanged	Unchanged	Return `503 feedback_unavailable`; events wait in memory (up to 1,000)
Forge is misconfigured (missing key, bad URL)	Unchanged: Forge logs one warning and turns itself off	Unchanged	Off until fixed
An optional value is invalid	Unchanged	Unchanged	On, with that option’s default
An internal error in Forge	Unchanged: the original response goes out	Unchanged	That call isn’t counted
Your `openapi.document` provider throws	The request goes to your own route	Unchanged	Unchanged

Forge never throws into your request, and never crashes your server at startup. The exception is strict: true, which you can set in CI to make bad configuration fail the build:

const forge = createForge({ ...options, strict: process.env.CI === "true" });

Check the state at runtime, for example on a health route:

app.get("/health", (req, res) => {
  const { enabled, configErrors, eventsDropped, lastError } = forge.diagnostics();
  res.json({ status: "ok", forge: { enabled, configErrors, eventsDropped, lastError } });
});

What does touch the network

Only Forge’s own routes, never your API routes:

GET /feedback/rate and POST /feedback forward the rating to the backend (3-second timeout).
GET /feedback/summary fetches the aggregate, cached for 30 seconds.

Memory

Up to 1,000 queued events if the backend is unreachable (the oldest are dropped first).
If Forge serves your /openapi.json, it holds that one response in memory while adding the rating routes (capped at 10 MB; larger documents pass through unchanged).

Get started

Integrations

Guides

Performance and reliability

The critical path

When something goes wrong

What does touch the network

Memory

​The critical path

​When something goes wrong

​What does touch the network

​Memory

The critical path

When something goes wrong

What does touch the network

Memory