​
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:
ResourceUse it for
https://www.hilt.so/llms.txtShort product answer, current scope, and safest starting points
https://www.hilt.so/llms-full.txtLonger product map, route boundaries, and do-not-claim guidance
https://www.hilt.so/.well-known/hilt-agent.jsonStructured agent discovery manifest
https://www.hilt.so/agent-catalog.jsonPublic catalog for routes, offers, tools, and safe actions
https://www.hilt.so/v1/catalogWebsite discovery catalog for agents
https://www.hilt.so/v1/promptsRecommended prompts for Hilt integration planning
https://www.hilt.so/v1/sample-flowSample payment-to-access implementation flow
https://api.hilt.so/v1/openapi.jsonHilt API contract, including /v1/access
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: 
Read Hilt llms.txt, llms-full.txt, agent-catalog.json, /v1/catalog, /v1/prompts, /v1/sample-flow, and the OpenAPI schema. Build a Hilt Pay API integration plan for my paid API. Use /v1/access only for API product calls.

Protect my API endpoint with Hilt Pay API. The backend must call POST /v1/access/entitlements/check before serving content. If access is missing, return HTTP 402 with a Hilt-created x402 payment requirement.

Add native Solana USDC subscription access with Hilt. Use billing_model: "recurring" and renewal_mode: "solana_native_subscription". Do not claim non-Solana settlement options are live.

Audit my Hilt Pay API integration. Check that API keys are server-side, webhook signatures are verified, idempotency keys are used on writes, entitlement checks gate protected content, and x402 is described as HTTP 402 protocol shape.

Generate a safe owner approval summary for a Hilt Pay API setup manifest. Include app, product, price, protected resource, webhook endpoint, settlement rail, billing model, sandbox status, live actions requiring owner approval, and remaining risks.

​
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 Hilt entitlement state as the access decision. 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
  • protected resources call 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 and entitlement checks have been validated
  • owner approval covers live keys, billing, payout wallet configuration, and production use