UmbraUmbrafeed
Open Dashboard

Getting started

Authentication

Use a subscription API key. Its machine plan supplies the allowed surfaces, freshness bounds and request quota.

API keys

Keys are issued from your profile once you hold a machine-API plan. Pass the key in the apikey header, or as a standard Authorization: Bearer — the gateway accepts both forms on every machine surface (REST, WebSocket upgrades, MCP):

bash
# either form works
curl -H "apikey: $UMBRA_API_KEY" \
  "https://api.umbrafeed.com/api/v1/data/symbols/search?q=BTC&limit=5"

curl -H "Authorization: Bearer $UMBRA_API_KEY" \
  "https://api.umbrafeed.com/api/v1/data/symbols/search?q=BTC&limit=5"

If both headers are present, Authorizationwins. For WebSocket, supply the key via your client's header support (the gateway authenticates the upgrade). Your tier and rate limit are derived from the key — see Access tiers. These production routes are live; the separate planned /v1reference is not.

Keep keys server-side

A key carries your tier and quota. Never ship it in browser or mobile client code — proxy requests through your backend. Rotate or revoke compromised keys from the API-keys tab.

Planned x402 access

x402 has published display pricing, but no public 402 route or self-serve x402 checkout is deployed today. It is intended for delayed request/response access, not WebSocket or live production use. Contact us before implementing against an x402 flow.

Consumer identity

Behind the gateway, every request resolves to the API-key owner for entitlements, quota and revocation. Live /api/v1/dataresponses keep their service-native typed schemas. The per-consumertrace watermark documented in the planned /v1reference is not part of the live rail yet.