SDKs and Postman

Use this page when you want the fastest copy-paste path after Developer quickstart. Hilt publishes official public developer assets for the API:
  • TypeScript SDK
  • Python SDK
  • Postman collection
  • Postman environment
These assets describe the same supported public API contract as the developer docs, OpenAPI schema, examples, and agent-readable files. These stay aligned with the same public merchant routes documented elsewhere in Hilt docs:
  • products
  • hosted checkout
  • payments
  • Hilt Pay API
  • agent bootstrap and setup intents
  • rail settings and setup readiness
  • payment sessions, proof submission, and entitlement checks
  • memberships
  • receipts
  • support
  • webhooks

Common questions

Does Hilt publish official SDKs?

Yes. Hilt publishes official TypeScript and Python SDKs, plus Postman assets for teams that want to inspect the API before writing code.

Which SDK should I start with?

Use the TypeScript SDK for Node.js backends and frontend-adjacent tooling. Use the Python SDK for Python services, scripts, support automation, and data workflows.

Is Postman still useful if I use an SDK?

Yes. Postman is the fastest way to inspect object shapes, test authentication, send webhook test events, and compare API behavior before putting the call into code.

30-second SDK proof

If you only want to prove the published SDKs install and can talk to Hilt, use one of these smallest possible reads.

TypeScript

Python

Success looks like:
  • the package installs cleanly
  • auth works
  • the SDK returns the same products your workspace sees in Hilt
Representative output:

Node .env.local

Python .env

TypeScript quickstart

Install

Source and releases:
  • npm: https://www.npmjs.com/package/@hiltpay/sdk
  • GitHub: https://github.com/Hiltpay/hilt-sdk-js

Copy-paste example

Expected result:
  • one active product in Hilt
  • one reusable product.id
  • one reusable slug
  • one buyer-facing checkout payload you can compare against the dashboard

Hilt Pay API durable entitlement check

Use checkEntitlement for durable or time-based access display and planning. For each metered request, use atomic consumption instead:

Hilt Pay API payment session

Use checkoutUrl for hosted Solana USDC checkout. Use paymentRequirement only when Hilt returns one for the protected-resource protocol path.

Settle an x402 V2 paid retry

When a buyer retries your protected resource with PAYMENT-SIGNATURE, settle it through Hilt before consuming the metered unit:
Relay PAYMENT-RESPONSE to the buyer, atomically consume one unit with the same logical request id, and serve only after both operations succeed.

Hilt Pay API agent bootstrap

Python quickstart

Install

Source and releases:
  • PyPI: https://pypi.org/project/hilt-sdk/
  • GitHub: https://github.com/Hiltpay/hilt-sdk-python

Copy-paste example

Expected result:
  • one product created from Python
  • one clean product["id"]
  • one repeatable receipts query for later proof handling

Hilt Pay API durable entitlement check

Use check_entitlement for durable or time-based access display and planning. For metered work:

Hilt Pay API payment session

Use the returned Hilt session state to build the 402 response or hosted checkout handoff.

Settle an x402 V2 paid retry

Relay PAYMENT-RESPONSE, atomically consume one unit with the same logical request id, and serve only after both operations succeed.

Sandbox session helpers

Use sandbox sessions to validate SDK, webhook, receipt, and entitlement handling without live money. TypeScript:
Python:

Webhook helpers

Both SDKs include raw-body verification helpers for Hilt webhooks. Hilt signs <timestamp>.<raw_json_body> and sends X-Hilt-Signature as t=<unix_timestamp>,v1=<hex_hmac_sha256>. TypeScript:
Python:

Error handling

Both SDKs raise HiltApiError for non-2xx API responses. The error includes:
  • code
  • statusCode or status_code
  • requestId or request_id
  • retryable
  • docsUrl or docs_url
  • safe response body details
Use the Errors and status handling catalog for recommended action by code. SDK docs URLs point to anchors such as /developers/errors#payment-failed, /developers/errors#idempotency-in-progress, and /developers/errors#request-timeout. TypeScript:
Python:

Subscription helper boundary

The SDKs expose the current public native subscription routes:
  • read a native subscription authorization
  • create a cancellation intent
  • confirm the signed cancellation
Public endpoints for list, pause, resume, and browser-safe customer management sessions are not exposed yet, so the SDKs do not fake those methods. Build recurring access today with a recurring product, a payment session, signed webhooks, and entitlement checks. Proposed backend contract for future high-level subscription helpers:
The browser-facing contract should return only a short-lived customer token or hosted management URL. It must never expose a Hilt API key in browser code.

Hilt Pay API agent bootstrap

Postman quickstart

Use the public developer-assets repo for the mirrored machine-readable assets:
  • https://github.com/Hiltpay/hilt-developer-assets
Import:
  • postman/hilt-postman-collection.json
  • postman/hilt-postman-environment.json

Set these environment variables

The shipped environment already includes these keys:
  • baseUrl
  • apiKey
  • bearerToken
  • merchantWallet
  • productId
  • slug
  • paymentId
  • payApiAppId
  • payApiProductId
  • membershipId
  • receiptId
  • endpointId

Run these requests in order

  1. Products -> Create product
  2. Hilt Pay API -> List Pay API rails
  3. Hilt Pay API -> Create agent bootstrap
  4. Hilt Pay API -> Submit setup manifest
  5. Hilt Pay API -> Check setup readiness
  6. Hilt Pay API -> Settle x402 V2 payment
  7. Hilt Pay API -> Consume metered entitlement
  8. Hilt Pay API -> Check durable entitlement
  9. Webhooks -> Create webhook endpoint
  10. Webhooks -> Send test event
  11. Testing -> Create sandbox session
What you should capture as you go:
  • productId
  • slug
  • endpointId
  • fake sandbox ids such as fake_payment_id and fake_receipt_id

Why Postman is useful here

Postman is the fastest way to verify:
  • your auth surfaces are correct
  • the public API matches the docs
  • webhook endpoint management works with a bearer token
  • sandbox responses match the object shapes your application expects

Contract and fallback assets

The supported public developer surface is represented by:
  • these developer docs
  • the TypeScript SDK
  • the Python SDK
  • the Postman collection and environment
  • approved snapshots in the developer-assets repo
For Hilt Pay API, the contract must also preserve:
  • the /v1/access implementation namespace
  • solana_usdc as the first production settlement rail
  • x402 as the 402 Payment Required protocol shape for protected-resource flows
  • scoped API keys for server and agent integrations
  • receipt, entitlement, webhook, and audit retrieval through API
If you want Hilt-hosted fallback imports instead of GitHub:
  • https://www.hilt.so/downloads/hilt-postman-collection-latest.json
  • https://www.hilt.so/downloads/hilt-postman-environment-latest.json
If you want a Hilt-hosted Python package artifact instead of PyPI:
  • https://www.hilt.so/downloads/hilt_sdk-1.2.0-py3-none-any.whl

Auth surfaces

For most merchant requests in the SDKs and Postman collection, use:
Webhook endpoint management currently requires a dashboard session token:
That is why the webhook methods in the SDKs and the webhook requests in the Postman collection use the bearer-token surface instead of an API key.

What to do after the SDK quickstart

  • run a signed test webhook event
  • create one sandbox session
  • check setup readiness before live traffic
  • verify payment, membership, receipt, and delivery state afterwards
For that exact flow, go back to Developer quickstart and Testing and going live.