API reference

API rate limits

Written and maintained by The ProspectAPIs team

The ProspectAPIs API rate limit is a cap of 60 requests a minute per API key, counted separately for the REST API and the hosted MCP server. Every limited response carries RateLimit headers that show what is left, and a request over the limit gets a 429 with a Retry-After header. A refused request is never billed.

Limits by surface

Surface	Limit	Counted
/v1 (every REST endpoint)	60 requests a minute	per API key
/mcp (the hosted MCP server)	60 messages a minute	per API key, a separate counter
POST /v1/watchlists/:id/test	5 test deliveries a minute	per account
POST /v1/feedback	10 reports an hour	per account

Windows are fixed 60 second windows (an hour for feedback). Each MCP tool call also makes one /v1 request with the same key, so it counts against both counters. Test deliveries and feedback are counted per account, so creating more keys does not raise them.

RateLimit headers

The limit is checked after your key is validated and before anything is charged, and every response it lets through carries:

Header	Meaning
RateLimit-Policy	The limit and the window in seconds, for example 60;w=60.
RateLimit-Limit	Requests allowed in the current window.
RateLimit-Remaining	Requests left in the current window.
RateLimit-Reset	Seconds until the window resets.
Retry-After	On a 429 only: seconds to wait before the next request.

Response headers

RateLimit-Policy: 60;w=60
RateLimit-Limit: 60
RateLimit-Remaining: 41
RateLimit-Reset: 23

429 Too Many Requests

A REST request over the limit answers:

429 Too Many Requests

{ "error": "Too many requests. Limit: 60 per minute per key." }

The hosted MCP server answers the same status with a JSON-RPC error, code -32000, and the same message. Nothing is reserved or billed for a refused request.

Backing off

Read Retry-After and wait that many seconds before the next request; never retry in a tight loop. To stay under the limit, watch RateLimit-Remaining and slow down as it nears zero. One paged GET /v1/funding call returns up to 100 records, so a larger page is usually the cheapest way to make fewer requests.

JavaScript

async function call(url, key) {
  for (let attempt = 0; attempt < 5; attempt++) {
    const res = await fetch(url, { headers: { Authorization: `Bearer ${key}` } });
    if (res.status !== 429) return res;
    const wait = Number(res.headers.get("Retry-After") ?? 1);
    await new Promise((r) => setTimeout(r, wait * 1000));
  }
  throw new Error("still rate limited after 5 attempts");
}

const res = await call("https://api.prospectapis.com/v1/funding?since=2026-10-01&limit=100", process.env.PROSPECTAPIS_KEY);

Python

import os, time, requests

def call(url, key, attempts=5):
    for _ in range(attempts):
        res = requests.get(url, headers={"Authorization": f"Bearer {key}"}, timeout=30)
        if res.status_code != 429:
            return res
        time.sleep(int(res.headers.get("Retry-After", "1")))
    raise RuntimeError("still rate limited after 5 attempts")

res = call("https://api.prospectapis.com/v1/funding?since=2026-10-01&limit=100", os.environ["PROSPECTAPIS_KEY"])

More room

If a steady workload needs more than 60 requests a minute, tell us what you are building with POST /v1/feedback, and see watchlists to have new funding rounds pushed to you instead of polling for them. How a pushed round turns into a researched prospect is in funding signals prospecting.

Create a free account to get a key, then send your first request with the samples above.