d.pro Authentication
API key authentication for the Public Data API, and wallet-based JWT for d.pro backend features.
d.pro's Public Data API uses API key authentication (x-api-key header). The d.pro backend API uses a wallet-based JWT session. Both are covered on this page.
Get an API key
Open the developer portal
Go to d.pro/developers and connect your wallet.
Pick your tier (optional)
Every account — including the free tier — gets an API key and can start calling right away. The free tier is rate-limited with no credit cost; Pro and Max raise the rate limit and add a generous monthly credit quota — see VIP and the tiers on d.pro/vip.
Create a key
On the API keys tab, name a key and create it. The plaintext key is shown only once — copy and store it securely. You can hold up to 5 active keys and revoke any of them at any time.
Authentication
Send your key in the x-api-key request header on every call. For example, to fetch trending assets you would call GET /api/public/v1/hl/trending?period=1h with the header x-api-key: YOUR_KEY.
A missing or invalid key returns 401 Unauthorized with code INVALID_API_KEY.
Treat your API key like a password. It is tied to your account's credits and quota. Call the API server-side — never ship your key in browser, mobile, or other client-side code where it can be extracted. If a key leaks, revoke it from the developer portal and create a new one.
Tiers
| Tier | Rate limit | Monthly credits |
|---|---|---|
| Free | 60 req/min | — (not metered) |
| Pro | 200 req/min | 10,000,000 credits |
| Max | 600 req/min | 100,000,000 credits |
Credit-billing mechanics, the X-RateLimit-* headers, and INSUFFICIENT_CREDITS are covered in Conventions → Rate limits & credits.
Wallet JWT (d.pro backend API)
The following section applies to the d.pro backend API (/api/v1/*) only — distinct from the Public Data API key above.
d.pro uses a wallet-based JWT authentication system. Users prove ownership of their wallet address by signing a backend-generated challenge, then receive a JWT session token for subsequent API calls.
This is separate from Hyperliquid's on-chain transaction signing. You need both:
- d.pro JWT — for d.pro API features (referrals, OPC, watchlist, cohort)
- Hyperliquid signature — for on-chain actions (orders, transfers, approvals)
Hyperliquid itself is stateless — it validates on-chain signatures. The d.pro JWT layer exists purely to support d.pro's stateful application features.
Authentication flow
Request a login challenge
POST /api/v1/auth/login
Content-Type: application/json
{
"address": "0xYOUR_WALLET_ADDRESS"
}Response:
{
"message": "Sign this message to authenticate with d.pro: nonce_abc123_1708622398623",
"nonce": "nonce_abc123_1708622398623"
}The message is a random challenge that expires after a short window (typically 5 minutes).
Sign the challenge with your wallet
Use your wallet's personal_sign (EIP-191) to sign the message string returned in step 1.
In a browser wallet:
const signature = await window.ethereum.request({
method: 'personal_sign',
params: [message, address],
});With ethers.js:
const signature = await signer.signMessage(message);Submit the signed message
POST /api/v1/auth/sign-message
Content-Type: application/json
{
"address": "0xYOUR_WALLET_ADDRESS",
"message": "Sign this message to authenticate with d.pro: nonce_abc123_1708622398623",
"signature": "0xSIGNATURE_HEX"
}The backend:
- Recovers the signer address from the signature
- Verifies it matches the
addressfield - Checks the nonce has not been used before
- Returns a JWT token
Response:
{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"expiresAt": "2025-05-22T10:00:00Z"
}Use the JWT token
Include the token in the Authorization header for all protected d.pro API calls:
GET /api/v1/referral/status
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Refresh the token
Before the token expires, refresh it to extend the session:
POST /api/v1/auth/refresh
Authorization: Bearer CURRENT_TOKENResponse:
{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9_NEW...",
"expiresAt": "2025-06-22T10:00:00Z"
}The old token is invalidated. Replace it in your application storage.
Token storage
- Browser: Store in
localStorageorsessionStorage.localStoragepersists across sessions;sessionStorageclears on tab close. - Server / Bot: Store in an environment variable or secure secrets manager. Never commit tokens to source control.
JWT tokens grant full access to d.pro's API features for your wallet. Treat them like a password. If you suspect a token is compromised, log out (which invalidates the token) and re-authenticate.
Security model
d.pro's JWT auth is designed for application-layer features only. It cannot:
- Move funds on Hyperliquid
- Place orders on Hyperliquid
- Approve builder fees
All on-chain actions still require a valid on-chain signature from your wallet or an authorized Agent Key. The JWT is purely for d.pro's own API (referrals, OPC, watchlist, cohort management).
API Overview
d.pro's three API surfaces — Public Data API, d.pro Backend API, and Hyperliquid API — what each covers and when to use which.
Conventions
Shared conventions for all Public Data API endpoints — response envelope, symbol formats, pagination, timestamps, rate limits, credits, data freshness, recipes, and errors.