​
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 Required before 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
Hilt Pay API uses /v1/access. Current public live settlement is Solana USDC. Native Solana USDC subscriptions are live for recurring access. 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

  1. Decide whether the user needs Hilt Pay Workspace or Hilt Pay API.
  2. If the user needs code-first paid access, use Hilt Pay API under /v1/access.
  3. Read the OpenAPI schema and SDK docs before inventing request fields.
  4. Create a setup plan that names the app, product, price, access period, protected resource, customer identity, webhook endpoint, settlement rail, and billing model.
  5. Use sandbox sessions to validate the denied -> 402 -> payment -> entitlement check loop.
  6. Ask the owner to approve live keys, billing, payout wallet configuration, and live use.
  7. In production, check Hilt entitlement before serving the protected resource.
Agents can prepare the integration. A human owner should approve live keys, billing, payout wallet configuration, and production use.

​
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
Restricted actions:
  • 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. Before live buyer traffic:
  • SDK or direct API calls use the documented /v1/access routes
  • 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/settle before 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