Meter usage from your own gateway

Some teams route all model traffic through an internal proxy: for shared keys, logging, or because several services in different languages call models. The proxy sees every request, but not which customer or agent it was for. This guide splits the work across the boundary: your application checks the budget and sends attribution as headers, and the proxy reports what it observed.

If the response comes back into a Node process you control, wrapping the client there is simpler and also gives you the gateway’s real cost. Use this pattern for traffic you cannot wrap, for example from services in other languages.

Before you start:

A Stigg server API key in both the application and the proxy.
A metered feature or credit currency to bill against. This guide reports to the credits currency in sync mode, so no meter configuration is needed.

Check and send attribution from the application

Check the budget before sending the request, then add the attribution headers.

import { StiggAgentSDK } from '@stigg/agent-sdk-js';

const stigg = new StiggAgentSDK(process.env.STIGG_SERVER_API_KEY);

const context = {
  customerId: 'customer-acme',
  entitlement: { currencyId: 'credits' },
  agentId: 'agent-support-bot',
  attributionKey: 'agentId',
};

const decision = await stigg.check(context);
if (!decision.hasAccess) return showRemedy(decision);

await fetch(`${PROXY_URL}/v1/chat/completions`, {
  method: 'POST',
  headers: { 'content-type': 'application/json', ...stigg.governanceHeaders(context) },
  body: JSON.stringify({ model: 'gpt-5', messages }),
});

The headers carry the customer, the attribution dimensions (here {"agentId":"agent-support-bot"}), the attribution key that names the agent, and a correlation ID. They contain no secrets.Applications in other languages can set the same headers by hand: x-stigg-customer-id, x-stigg-dimensions (a JSON object), x-stigg-attribution-key (the key in x-stigg-dimensions that names the agent, here agentId) and x-stigg-run-id.

Report from the proxy

After the upstream call returns, report the usage with the incoming request’s headers:

import { StiggAgentSDK, unitsPerTokens } from '@stigg/agent-sdk-js';

const stigg = new StiggAgentSDK(process.env.STIGG_SERVER_API_KEY);

// In your request handler:
const completion = await upstream.chat.completions.create(body);

const result = await stigg.ingestFromHeaders(req.headers, {
  vendor: 'openai',
  usage: completion.usage,
  idempotencyKey: completion.id,
  entitlement: { currencyId: 'credits' },
  metrics: unitsPerTokens('credits', 1_000),
  ingest: 'sync',
});

res.json(completion);

vendor names the response shape the proxy observed: openai, openai-responses, anthropic, gemini or typesafe.
idempotencyKey should be the upstream request ID, so a retried report is not counted twice.
Reporting never throws. Answer the caller even if result.ok is false, and log the failure.
Requests without an x-stigg-customer-id header are not attributed.

Verify

Send a request through the proxy and open customer-acme in the Stigg app. The credit balance drops by the reported amount, and the usage is attributed to agent-support-bot and every level above it.

Limits of this pattern

The proxy cannot deny a call. Only the application holds the budget context, so the check happens there. A request that skips the check is still metered, but not gated.
Tokens, not cost. What crosses the boundary is a usage report. To bill the gateway’s real cost, wrap a gateway you call instead.
No double metering. Do not also wrap the client in the application for the same requests, or usage is reported twice.

Quick start guides

Integration guides

Credits

AI agents and LLMs

Trials

Pricing and monetization

Subscriptions and access

Billing and checkout

Platform and operations

Meter usage from your own gateway

Limits of this pattern

​Limits of this pattern

Limits of this pattern