Build paid API access with Grok Build

Use this guide when Grok Build is helping you add Hilt Pay API to an API, AI tool, bot, dataset, paid software feature, or private endpoint. The public example is a complete Next.js application, not only a prompt. It contains:
  • a protected server route
  • Hilt entitlement checks
  • HTTP 402 Payment Required responses
  • Hilt Pay API payment-session creation
  • local, sandbox, and live modes
  • a server-only development confirmation route
  • signed webhook verification
  • route-flow tests
  • AGENTS.md instructions and a Grok project skill
Hilt and Grok Build are separate products. This guide documents compatibility with Grok Build’s public agent instructions, project skills, headless mode, and MCP support. It does not describe an xAI partnership.

What each product does

Current public live settlement is Solana USDC. x402 is the HTTP 402 Payment Required protected-resource protocol shape. It is not a blockchain, token, wallet, chain, or settlement rail.

1. Install Grok Build

Use the official Grok Build installer for your operating system. macOS, Linux, or WSL:
Windows PowerShell:
Then authenticate and verify the installation:
Official Grok Build documentation: https://docs.x.ai/build/overview

2. Get the runnable Hilt example

The example is also indexed by Hilt’s agent manifest, catalog, LLM files, and developer documentation.

3. Run without a Hilt key

The default local mode proves the application control flow without moving money or claiming a Hilt receipt. macOS, Linux, or WSL:
Windows PowerShell:
Open http://localhost:3000 and complete this flow:
  1. Request the protected report.
  2. Confirm that the server returns HTTP 402.
  3. Confirm that the response says payment_protocol: "x402" and settlement_rail: "solana_usdc".
  4. Run the clearly labelled local confirmation.
  5. Retry the protected route.
  6. Confirm that the route serves the report only after the entitlement becomes active.
Local mode is a simulation. It does not create a live payment, Hilt receipt, or on-chain transaction.

4. Let Grok inspect the contract

From the example directory:
Grok Build should report the repository AGENTS.md file and the hilt-pay-api project skill. Use this prompt:
For a headless review, the example includes:
That command passes the checked-in PROMPT.md to Grok Build and requests JSON output. It does not pass Hilt credentials in the prompt.

5. Choose the right mode

Hilt sandbox mode

Create a Hilt Pay API sandbox product, then update .env.local:
Restart the example and run the browser flow again. The sandbox proof remains in server memory and is never returned to the browser. The example calls:

Live mode

After the owner has approved live setup, billing, payout wallet configuration, live API key scopes, and webhook configuration:
Live mode calls:
The payment-session request explicitly uses:
The development confirmation route returns 409 in live mode. The buyer or buyer-agent must complete the real payment path. Your server then checks Hilt entitlement again before serving the protected resource.

Implementation contract

The entitlement check is the access decision. Do not serve paid work from a wallet signature, transaction hash, client claim, pending payment session, or webhook alone.

Optional Agentverse discovery in Grok Build

Hilt can also be discovered through its Agentverse presence. Agentverse is an optional discovery path for Grok. Grok Build can connect to Agentverse MCP Lite because Grok supports remote MCP servers. This is optional. Agentverse helps the coding agent discover and inspect marketplace agents; it is not the Hilt Pay API transport and it is not required for the runnable example. macOS, Linux, or WSL:
Windows PowerShell:
Keep the token in the environment. Do not commit it to .grok/config.toml, AGENTS.md, prompts, or source code.

Verify the build

The included tests verify:
  • missing customer identity is rejected
  • unpaid access returns HTTP 402
  • the response separates x402 protocol from Solana USDC settlement
  • the local flow cannot be confused with a live payment
  • a session cannot be confirmed for a different customer
  • protected content is served only after entitlement is active
  • API keys and sandbox proofs do not appear in browser responses

Before live traffic

  • use a server-only Hilt API key with the required scopes
  • configure the correct Hilt Pay API product and Solana payout wallet
  • use a fresh attempt id for each logical checkout attempt
  • verify Hilt webhooks against the raw body and X-Hilt-Signature
  • store processed webhook event ids durably and process events idempotently
  • complete sandbox validation
  • let the owner approve live keys, billing, payout wallet configuration, and live use
  • test the denied -> 402 -> payment -> entitlement -> retry loop