​
Developer overview

Hilt Pay API gives developers and agents the API, SDK, CLI, webhook, Postman, OpenAPI, and GitHub asset surface for payment-to-access infrastructure. Use it to create products, return x402 HTTP 402 Payment Required requirements over Solana USDC, open MPP channels for repeated metered work, create hosted Solana USDC or native SOL payment sessions, receive payment and access evidence, protect paid APIs or products, and keep your own systems in sync. For metered agent payments, treat Hilt Pay API as the operating layer behind the paid-resource loop: atomically consume usage, return HTTP 402 when payment is needed, settle the buyer’s retry through Hilt, atomically consume one unit, and only then serve the result. If you want the shortest TypeScript path, start with Protect an endpoint. If you want the complete Python proof, copy the FastAPI protected-resource demo: denied request, HTTP 402, payment, settlement, atomic consumption, and paid retry. If you are protecting an API, AI tool, dataset, bot, or private software feature, use Hilt Pay API. If one payer will make many small purchases in a stream or working session, use Metered payment channels. If an agent or developer tool is setting up the integration for the owner, use Agent setup. If you want the broader model first, stay here.

​
What Hilt is good at

Hilt works best when you want one system to own the operational state around payment:
  • hosted checkout
  • agent setup intents
  • x402 protected-resource requirements
  • MPP session channels with capped escrow and cumulative usage vouchers
  • payment state
  • memberships and recurring operations
  • entitlements and paid-access checks
  • receipt proof
  • support context
  • webhook event delivery
  • payment-to-access checks for APIs, bots, datasets, and paid software
That means your own backend does not need to rebuild payment records, receipts, memberships, and support history after payment.

​
The fastest reliable implementation path

The practical build order is:
  1. choose Workspace or API as the primary surface
  2. create a sandbox setup intent or create one product from code
  3. configure Solana USDC rail settings and webhook endpoint
  4. install the SDK or import Postman
  5. test the denied -> 402 -> payment -> proof -> entitlement path in sandbox
  6. confirm live readiness before real buyer traffic
That gives you:
  • one working product
  • one working integration
  • one real merchant trail to compare against

​
What your backend should own

Your backend is usually the right place for:
  • product creation or updates when needed
  • signed buyer handoff link generation
  • webhook consumers for longer-running automation
  • active checkout polling while the buyer is still waiting
  • your own correlation between users and Hilt ids

​
What Hilt should own

Hilt should remain the source of truth for:
  • payment settlement state
  • membership state
  • renewal intelligence
  • receipt proof
  • support case history

​
Start from a real merchant workspace

The cleanest integrations start from a real merchant workspace rather than a purely synthetic setup:
  1. launch the first flow in the dashboard
  2. create the API key for that workspace
  3. automate the same product and checkout flow from your backend
  4. compare the API trail against what the merchant sees in the app
That keeps the integration aligned with the live commercial object the merchant already understands.

​
Use the right auth surface

For merchant-only routes, Hilt accepts either a merchant session token or an API key. Practical rule:
  • use X-Hilt-Key for almost all backend work
  • use Authorization: Bearer JWT_TOKEN for webhook endpoint management

​
API at a glance

​
The ids worth keeping

These are the ids worth persisting in your own system:
  • product_id
  • slug
  • payment_id
  • access_product_id
  • external_product_id
  • membership_id
  • receipt_id
  • ticket_id
The most important one is payment_id. It is the clean join between:
  • checkout state
  • payment status
  • memberships
  • receipts
  • support tickets
  • webhook timelines

​
Reference and tooling

Hilt publishes its developer surface in several forms:
  • TypeScript SDK: npm install @hiltpay/sdk
  • TypeScript SDK source: https://github.com/Hiltpay/hilt-sdk-js
  • Python SDK: pip install hilt-sdk
  • Python SDK source: https://github.com/Hiltpay/hilt-sdk-python
  • Developer assets repo: https://github.com/Hiltpay/hilt-developer-assets
Use the GitHub developer-assets repo when you want public mirrors of:
  • approved OpenAPI snapshots
  • Postman imports
  • example webhook payloads
Use these docs, the SDKs, and the developer-assets repo as the supported public contract.

​
Rate limits

Hilt returns standard rate-limit headers on API responses:
  • X-RateLimit-Limit
  • X-RateLimit-Remaining
  • X-RateLimit-Reset
  • Retry-After on 429
Current defaults are:
  • unauthenticated public buyer routes: 120 requests per minute
  • authenticated accounts without a custom contract: 60 requests per minute
  • Workspace account tiers may carry higher account-wide limits
  • Enterprise: custom or effectively unlimited by contract
Hilt Pay API Live pricing is pay-as-you-go and does not require a monthly API subscription. Rate limits remain an operational control and are separate from the successful-settlement fee.

​
When to use the dashboard, API, SDK, Postman, or CLI

​
Common questions

​
What can developers build with Hilt?

Developers can create products, start hosted checkout sessions, receive signed webhooks, read payment and membership state, manage receipts, open support context, and automate merchant operations with SDKs, Postman, or the CLI.

​
What is the most important Hilt id to store?

Store payment_id. It joins the buyer checkout, payment state, membership state, receipt proof, webhook timeline, and support trail.

​
Should a developer start from the dashboard or API?

For Hilt Pay Workspace, start from one real merchant workspace. For Hilt Pay API, an agent can start with a sandbox setup intent, but the owner still approves live billing, payout wallet, API key scopes, and production enablement.

​
Go deeper