Charging for an API is not only a checkout problem. A metered paid API must decide whether this exact billable request can consume one usage unit right now.
Hilt Pay API is built for that loop. Your backend attempts atomic consumption, returns HTTP 402 when usage is missing, settles the paid retry over Solana USDC, and serves only after one unit is consumed.
This is also the core pattern behind agentic payments. An agent, app, or backend can request a resource, receive a payment requirement when usage is missing, pay through the live settlement path, and retry with the payment signature Hilt verifies.
01
Create the paid API product
Model the paid endpoint as a Hilt Pay API product with a stable external product id, price, access period, and Solana USDC as the live settlement rail.
02
Identify the request
Pass your customer id and a stable request id so settlement and usage consumption remain retry-safe.
03
Consume one unit
Call POST /v1/access/entitlements/consume before expensive work, private data, model output, or any billable response leaves your backend.
04
Create the payment session
If usage is missing, create a Hilt Pay API payment session and return HTTP 402 with Hilt's PAYMENT-REQUIRED header.
05
Settle, consume, serve
Settle the buyer's PAYMENT-SIGNATURE through Hilt, atomically consume one unit, and serve only after both succeed.
Atomic consumption is the critical call
Put atomic consumption immediately before the paid route does real work. Use one stable request id for each logical billable operation.
If Hilt returns `consumed: true`, serve the resource. If usage is missing, create a payment session and return Hilt's x402 V2 `PAYMENT-REQUIRED` header.
curl -X POST https://api.hilt.so/v1/access/entitlements/consume \
-H "Content-Type: application/json" \
-H "X-Hilt-Key: $HILT_API_KEY" \
-H "Idempotency-Key: consume-req-001" \
-d '{
"external_product_id": "pro-api",
"external_customer_id": "cust_123",
"units": 1,
"metadata": {"request_id": "req_001"}
}'What Hilt records after payment
The payment itself is only one part of the system. A paid API needs the operating record that proves access, helps support customers, and lets your own backend reconcile what happened.
payment session state
Solana USDC settlement evidence
receipt and proof trail
entitlement period
signed webhook events
support and audit context
When this pattern fits
Use this pattern when the thing being sold is access to a resource rather than delivery of a physical product. The product can be one-off or recurring. For recurring products, Hilt Pay API supports native Solana subscription setup with buyer approval and period-aware cancellation.
AI inference endpoints where a user pays for a monthly pro route
Datasets, research APIs, market data, or private feeds
Agent tools that should return HTTP 402 instead of a free response
Paid bots, automations, and private software features
Recurring API access using native Solana subscription products
Start building
Copy the protected-resource flow, then make it yours.
The docs include product creation, payment sessions, x402 settlement, atomic consumption, durable entitlement checks, native subscriptions, webhooks, and sandbox testing under `/v1/access`.