Authentication
API keys, paired devices, feature access and deployment credentials.
Choose a credential
| Client | Credential | How to get it |
|---|---|---|
| External integration | API key · ak_… | Manage API keys; upload access requires api.upload. |
| Desktop app | Device token · ahf_dev_… | Use the app’s pairing flow. See the device routes in the directory. |
| Website | Signed-in session | Used for account pages. A browser session cannot upload market data (403 devices_only). |
Send the credential as Authorization: Bearer <token>. Keep it in the external client’s environment or credential store, outside Lua source and exported data.
Set your environment
Use a credential issued by the same deployment you are calling. Choose your development deployment while building an integration; synthetic examples must not be uploaded to the production market.
export AHF_BASE="https://auctionhouse.fyi"
read -rsp 'API key: ' AHF_KEY; echo
export AHF_KEYAHF_BASE is the origin, without /api/v1. GET /api/v1/config identifies the deployment. The key prompts above keep the key itself out of shell history.
Check your permissions
curl --fail-with-body -H "Authorization: Bearer $AHF_KEY" "$AHF_BASE/api/v1/me"The response lists features and limits. API keys need api.read for most authenticated reads and api.upload for uploads. Device uploads require upload.device. Additional endpoint features still apply.
A bad bearer credential returns 401; it does not fall back to an anonymous read. A missing feature returns 403 with the required feature. See errors and retries.
Versioned contracts and runnable examples live with the source specification →.