​
Developer overview

Hilt gives developers a clean way to automate the same merchant workflow the dashboard already runs. That usually means:
  • create or update products from your backend
  • open buyer sessions through hosted checkout
  • keep the payment_id as your durable correlation key
  • read memberships, receipts, and support state after payment
API keys, the docs, and the CLI are available across every Hilt plan. Higher plans mainly change fees, support level, and operating comfort once the merchant is doing real volume.

​
Reference and tooling

Hilt does publish a machine-readable API contract. Use whichever surface fits your workflow:
  • OpenAPI spec: https://api.hilt.so/v1/openapi.json
  • Swagger UI: https://api.hilt.so/v1/docs
  • Redoc: https://api.hilt.so/v1/redoc
The raw OpenAPI includes dashboard and account infrastructure routes alongside the public merchant contract. For merchant integrations, start with the supported public contract documented here:
  • products
  • hosted checkout
  • payments
  • memberships
  • receipts
  • support
Hilt does not currently publish an official Postman collection or a generated typed SDK. If you want either of those, the OpenAPI spec is the right source to import into Postman or to generate your own typed client from your preferred tooling. The copy-safe examples in Hilt docs are still the best place to start if you want a fast working implementation path in TypeScript, Python, or cURL.

​
Start from a real merchant workspace

The fastest reliable path is:
  1. launch the first flow in the dashboard
  2. create an API key for the workspace
  3. automate products and checkout from your backend
  4. read post-payment state from Hilt instead of rebuilding it elsewhere
That keeps your integration aligned with what the merchant already understands in the app.

​
Use the right auth surface

For merchant-only routes, Hilt accepts either a merchant session token or an API key.
SurfaceTypical authBest use
Public checkout payload and buyer session startno authBuyer-facing hosted checkout
Merchant backend or bot automationX-Hilt-KeyServer-to-server integrations
Dashboard-session toolingAuthorization: Bearer JWT_TOKENMerchant browser workflows and session-assisted tools
Hilt does not currently use OAuth-style scopes for merchant integrations. Instead, API keys carry a small permission set:
  • read
  • execute
  • admin
  • billing
Those permissions are attached to the key itself and enforced server-side.

​
Public contract at a glance

AreaWhat you do thereMain routes
ProductsCreate, update, archive, and inspect merchant offers/v1/products
Hosted checkoutRead buyer payloads and start buyer sessions/v1/products/p/{slug}, /connect, /resolve-handoff
PaymentsConfirm or poll payment state/v1/pay/confirm, /v1/payments/{payment_id}
MembershipsRead access state and run follow-up actions/v1/memberships*
ReceiptsRead proof and public verification links/v1/receipts, /v1/receipt/{id}
SupportOpen and manage issue threads tied to the payment trail/v1/support/tickets*

​
Durable identifiers

These are the ids worth keeping in your own system:
  • product_id
  • slug
  • payment_id
  • membership_id
  • receipt_id
  • ticket_id
The most important one is payment_id. It is the clean join between buyer checkout, payment state, membership state, receipts, and support.

​
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, or CLI

SurfaceBest for
DashboardFirst launch, checkout branding, commercial setup, daily merchant operations
APIBackend automation, bots, signed handoff links, payment-state reads, ledger lookups
CLIFast terminal lookups, repeatable support workflows, light automation scripts

​
1. Launch one real product

Start with a dashboard template or create the same offer from POST /v1/products.

​
2. Read it through the API

Use GET /v1/products and GET /v1/products/{product_id} to make sure your backend sees the same commercial object the merchant sees.

​
3. Start the buyer session

Use POST /v1/products/p/{slug}/connect to get the canonical payment_id.

​
4. Keep the payment id everywhere

That id is the join between:
  • checkout state
  • payment status
  • memberships
  • receipts
  • support tickets

​
5. Read Hilt after payment

Once the buyer has paid, use Hilt as the source of truth for:
  • final payment state
  • access state
  • proof and verification
  • support follow-up

​
What a serious backend usually owns

Hilt works best when your backend owns:
  • product creation or updates when needed
  • signed handoff link generation
  • polling and post-payment reads
  • your own correlation between app users and Hilt ids
Hilt itself should remain the truth for:
  • payment settlement state
  • membership status
  • receipt proof
  • support case history

​
Go deeper