Paid API access

How to Charge for API Access with Solana USDC

A practical implementation guide for paid API access: create a product, check entitlement, collect Solana USDC, and serve only after access is active.

5 June 2026Implementation guide

Charging for an API is not only a checkout problem. A working paid API has to answer the same question on every request: does this customer have access right now?

Hilt Pay API is built for that loop. Your backend creates the product, checks entitlement before serving the resource, sends unpaid customers into Solana USDC payment, and serves the response only after Hilt returns active access.

This is also the core pattern behind agentic payments. An agent, app, or backend can request a resource, receive a payment requirement when access is missing, pay through the live settlement path, and retry once entitlement state is active.

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.

Identify the customer

Pass your own user or account id as external_customer_id so entitlement checks can answer whether this requester has access right now.

Check entitlement first

Call POST /v1/access/entitlements/check before expensive work, private data, model output, or any paid response leaves your backend.

Create the payment session

If access is missing, create a Hilt Pay API payment session and send the buyer or agent into the returned checkout or payment requirement.

Serve after active access

Retry the entitlement check after payment. Serve the API response only when Hilt returns has_access: true.

The access check is the critical call

Put the entitlement check in the same place you would normally check an API key, session, role, or plan. It should run before the paid route does real work.

If Hilt returns `has_access: true`, serve the resource. If it returns false, create a payment session and send back the checkout or x402 payment requirement your flow supports.

curl -X POST https://api.hilt.so/v1/access/entitlements/check \
  -H "Content-Type: application/json" \
  -H "X-Hilt-Key: $HILT_API_KEY" \
  -d '{
    "external_product_id": "pro-api",
    "external_customer_id": "cust_123"
  }'

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, entitlement checks, payment sessions, native subscriptions, webhooks, and sandbox testing under the `/v1/access` namespace.

Open API docs Add HTTP 402