​

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, send buyers or agents into Solana USDC settlement, receive payment, receipt, membership, and entitlement events, protect paid APIs or products with access checks, and keep your own systems in sync. For agentic payments, treat Hilt Pay API as the operating layer behind the paid-resource loop: discover the resource, check entitlement, return HTTP 402 when unpaid, complete payment, verify through Hilt, and retry only after access is active. If you want one working flow tonight, start with Developer quickstart. If you want the hero proof, copy the FastAPI protected-resource demo: denied request, HTTP 402, payment, proof, entitlement check, and access retry. If you are protecting an API, AI tool, dataset, bot, or private software feature, use Hilt Pay API. 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
• 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
• Free: 60 requests per minute
• Starter: 120 requests per minute
• Growth: 300 requests per minute
• Scale: 900 requests per minute
• Enterprise: custom or effectively unlimited by contract

​

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, CLI, or Zapier.

​

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

• Developer quickstart
• Hilt Pay API
• Agent setup
• API keys
• Products and checkout
• Testing and going live
• Webhooks
• Members, receipts, and support
• SDKs and Postman
• Examples
• CLI
• Developer playbooks