Authentication
All requests are authenticated with a bearer token sent in the Authorization header. The API does not use OAuth, sessions, or per-request signing.
Header format
Authorization: Bearer YOUR_KEYRequests without this header return 401 Unauthorized. Invalid keys return 401 with { "error": { "code": "unauthorized" } } in the response body. See errors for the full envelope.
Quickstart
Confirm a key is active by requesting any tracked ticker.
curl https://api.tickerbot.io/v1/tickers/AAPL \
-H "Authorization: Bearer YOUR_KEY"A 200 indicates the key is valid. 401 indicates the key is missing or invalid; 403 indicates the key is valid but the requested capability is not included in the key's plan.
Issuing keys
Keys are issued from the dashboard at tickerbot.io/api. The first key is shown after checkout; additional keys — for staging, CI, or per-environment isolation — are created from the dashboard.
Keys are independent. Usage counts, rate limits, and webhook ownership are scoped to the issuing key, not the account. Rotating a key does not transfer ownership of resources created by the previous key.
Plans
| Feature | Reads | Read + Write + Realtime |
|---|---|---|
| Daily request cap | 100,000 | 1,000,000 |
| Burst rate | 10 req/sec | 10 req/sec |
| Historical depth | 30 days | 1 year |
| GET /tickers/{ticker} and bulk | Yes | Yes |
| GET /signals/{ticker}/{signal} | Yes | Yes |
| GET/POST /scan | Yes | Yes |
| POST/GET/DELETE /webhooks | — | Yes |
| Crypto coverage (top 100 by mcap) | Yes | Yes |
| US equities coverage (~12,000 tickers) | Yes | Yes |
Handling keys
- Keys are credentials. Do not commit them to source control, embed them in mobile applications, or include them in browser bundles.
- Use separate keys for staging and production environments.
- Revoke exposed keys from the dashboard. Revocation takes effect immediately.