Loading…
Pulse MarketsPricing
Two things are stated plainly here because they are where API pricing usually gets slippery: what one request means, and what happens when you run out.
Sandbox
Real historical data, its own separate allowance, no card. Every account has sandbox access permanently, including paid ones.
Free
- Requests per minute
- 60
- Requests per 30 days
- 50,000
Free
End-of-day and 15-minute-delayed US equities, with a modest request allowance and permanent sandbox access on its own allowance.
Free
- Requests per minute
- 10
- Requests per 30 days
- 1,000
Developer
Real-time US equities and ETFs, fundamentals and news, full history, and a much higher request rate.
$49/mo
- Requests per minute
- 300
- Requests per 30 days
- 1,000,000
Business
Every asset class with WebSocket streaming, deep history, a very high request rate, and limited redistribution rights.
$199/mo
- Requests per minute
- 6,000
- Requests per 30 days
- 50,000,000
Enterprise
Uncapped throughput, full redistribution rights, and an SLA. Commercial terms are agreed per contract.
Contact us
- Requests per minute
- Uncapped
- Requests per 30 days
- Uncapped
The quota maths
What actually counts as a request.
- One HTTP request is one request. Not one per row returned, and not one per instrument in a bulk call. Asking
/v1/prices/bulkfor 200 instruments over a year costs one request; asking per-instrument in a loop costs 200. - Date range does not affect cost. One day of bars and ten years of bars cost the same.
- Sandbox requests cost nothing, ever. They are recorded in your dashboard so you can see them, but the limiter is never consulted.
- Failed requests still count against the live allowance, because they still cost us the work of authenticating and rejecting them. A 4xx caused by your own bug is not free, which is another reason to develop against sandbox.
- Both windows apply. The per-minute limit is burst control and the 30-day limit is volume. You need to stay inside both.
Worked example on the free tier: 1,000 requests per 30 days is about 33 a day. A daily job pulling end-of-day bars for 500 instruments via /v1/prices/bulk in batches of 50 is 10 requests a day, so roughly 300 a month - comfortably inside the tier. The same job written as a per-instrument loop is 15,000 a month and exceeds it many times over, which is what batching is for.
When you run out
You get an HTTP 429 with the rate_limited error code and a Retry-After header. Nothing is silently truncated, and you are never charged an overage you did not agree to.
You should never reach that point by surprise: every response carries X-RateLimit-Remaining, and your dashboard shows usage over time. Discovering a limit by hitting it is the most-cited complaint about competing APIs, and it is a design choice rather than an inevitability.
Cancellation is self-serve. There is no retention flow, no phone call, and no cancellation fee.