Skip to main content

API keys

Every request must include your API key in the X-API-Key header:
Keys are prefixed by environment:
  • hsh_sandbox_: sandbox keys (free, curated universe)
  • hsh_live_: live keys (the Plus plan, full universe)
Create and revoke keys from your API dashboard.
Live keys come with halal.sh Plus and are for your own use: research, automations, and internal workflows. To build a product on halal.sh, see the developer plans.A live key’s access follows your active subscription, not the moment the key was minted. If Plus lapses, existing hsh_live_ keys keep working but fall back to the sandbox universe and sandbox rate limits, and out-of-universe symbols start returning 403 sandbox_restricted. Renewing restores full access within five minutes; there is no need to mint a new key.
Treat your API key like a password. Never ship it in client-side code, a public repository, or a browser request. Always call the API from your backend.

The sandbox

Sandbox keys (hsh_sandbox_) return real data with the exact same response schema as production, scoped to a curated set of instruments: These cover every compliance state (compliant AAPL, non-compliant JPM and GS) and a range of sectors, so you can build and test against each path. Requesting any other symbol returns 403 sandbox_restricted. Filter-based screening (/screen without symbols) also requires an active Plus plan. The same scope applies to any caller without an active paid plan: a sandbox key, a live key on a lapsed subscription, or a signed-in session on Free.

Rate limits

Limits follow the caller’s current plan, not their credential type. Every response includes your current limit state:
When you exceed a limit, the API returns 429 with a Retry-After header and a retry_after field (seconds):
The daily window resets at midnight UTC.

Error handling

Every error uses the same envelope:
Always log meta.request_id. It uniquely identifies the request and speeds up support.

Response envelope

Every success response has the same shape:
meta.methodology is present on compliance-bearing responses and identifies the exact methodology version used. See Methodology versioning.

Versioning and stability

The API is versioned in the URL path (/v1). Within a version we guarantee:
  • no fields are removed or renamed,
  • no field types change,
  • no URL structure changes.
We may add fields, endpoints, optional parameters, and enum values within a version. Design your client to ignore unknown fields and to treat an unrecognised status as pending. Breaking changes ship as a new version (/v2) with a migration guide and a deprecation window for the previous one.

Support

Stuck, or seeing something that looks wrong? Contact us, and include the meta.request_id of any failing request so we can trace it.