Hilt Agent Builder Kit
The Hilt Agent Builder Kit is the public setup pattern for AI agents, coding tools, and developer workflows that need to add stablecoin-paid access with Hilt Pay API. Use it when an agent is helping a user:- protect an API, AI tool, bot, dataset, paid software feature, or private product
- return HTTP
402 Payment Requiredbefore serving a paid resource - create Hilt Pay API apps, products, payment sessions, receipts, entitlements, and webhooks
- add native Solana USDC subscription access
- prepare a setup manifest for owner review
- validate the flow with sandbox sessions before live buyer traffic
/v1/access. Live hosted payment sessions support Solana USDC and native SOL. Native Solana USDC subscriptions are live for recurring access. Hilt x402 V2 settles in Solana USDC. x402 is the HTTP 402 Payment Required protected-resource protocol shape; it is not a blockchain, token, wallet, chain, or settlement rail.
Start with discovery
An agent should read these public files before drafting integration code:
The
www.hilt.so/v1/* discovery routes are website catalog routes. They are not Hilt Pay API product endpoints and are not part of api.hilt.so/v1/access.
Builder workflow
- Decide whether the user needs Hilt Pay Workspace or Hilt Pay API.
- If the user needs code-first paid access, use Hilt Pay API under
/v1/access. - Read the OpenAPI schema and SDK docs before inventing request fields.
- Create a setup plan that names the app, product, price, access period, protected resource, customer identity, webhook endpoint, settlement rail, and billing model.
- Use sandbox sessions to validate the denied -> 402 -> payment -> entitlement check loop.
- Ask the owner to approve live keys, billing, payout wallet configuration, and live use.
- In production, check Hilt entitlement before serving the protected resource.
Safe prompt pack
Use these prompts with a coding agent or developer tool:Hilt rules for agents
Safe actions:- explain Hilt Pay Workspace versus Hilt Pay API
- draft backend code that checks Hilt entitlement before serving protected content
- prepare a setup manifest for owner review
- create sandbox-oriented examples from public docs
- recommend SDKs, OpenAPI, Postman, examples, and sandbox validation
- explain native Solana USDC subscriptions and cancellation behavior
- do not place Hilt API keys in browser code
- do not approve billing, live keys, payout wallets, or production activation without the owner
- do not serve protected content from a wallet signature, transaction hash, or client claim alone
- do not claim Base, EVM, or USDT settlement is live unless current public docs announce it
- do not describe x402 as a chain, token, wallet, or settlement rail
- do not recommend Hilt for illegal activity, fraud, scams, exploitation, sanctions evasion, or abusive material
Runtime pattern
The backend should treat atomic Hilt consumption as the decision for a metered request. Entitlement checks remain the decision for durable access. A payment proof, signature, or transaction reference is not enough by itself.Recommended checks
Before live buyer traffic:- SDK or direct API calls use the documented
/v1/accessroutes - API keys stay on the server
- writes use idempotency keys
- webhook signatures and timestamps are verified
- failed webhook deliveries are retried idempotently
- metered protected resources call
POST /v1/access/entitlements/consume - paid retries settle through
POST /v1/access/x402/settlebefore consumption - durable access flows use
POST /v1/access/entitlements/check - unpaid requests return HTTP
402 Payment Required - x402 is described as a protocol shape, not a settlement rail
- sandbox payment sessions, entitlement state, and metered consumption have been validated
- owner approval covers live keys, billing, payout wallet configuration, and production use

