How Do I Make My First Prediction Market API Call

The Short Answer
Your first prediction market API call is one authenticated GET. Create a key, send it as an Authorization: Bearer pk_live_... header to https://data.predictefy.com/api/kalshi/fetchMarkets, and read the JSON that comes back. Nothing needs funding, and reads never touch your money. The free plan covers 25,000 credits a month at 60 requests per minute, on 1 API key and 2 WebSocket streams, for $0. The same path shape works on every venue Predictefy normalizes.
Most people do not get stuck on the request. They get stuck on everything around it: which venue, which endpoint, which auth scheme, and what the numbers in the response actually mean.
A prediction market quote can arrive as cents, as a decimal probability, as a share price, or as an odds line, depending on whose API you called. Two venues can list the same event under different resolution wording. That is why a first call that "works" often still leaves you holding data you cannot compare.
This walkthrough gets you a real response, then explains what to do with it.
Key Takeaways
- A first call needs three things: an API key, a venue name, and a verb, in the path shape
/api/{venue}/{verb}. - The Predictefy free plan is $0 and includes 25,000 credits per month, 60 requests per minute, 1 API key and 2 WebSocket streams.
- Reading market data and placing orders live behind different services, and that separation is deliberate.
- Across 5,000 live Kalshi markets measured on 3 September 2026, 18.1% had no bid at all, so a midpoint in the response is not automatically a tradable price.
- Predictefy normalizes 15+ venues into one schema, and the free plan reads all of them, so trying a cross-venue read costs nothing.
What do I need before my first prediction market API call?
You need an API key and a way to send an HTTP request. That is the whole list.
You do not need a funded account, a wallet, a signing library or venue approval to read market data. Those only matter once you want to place an order, and that is a separate step covered further down. Read access is the cheap, reversible part, and it is where every integration should start.
Sign up, generate a key, and store it once. Keys carry the pk_live_ prefix and travel in an Authorization header, and the free plan includes one of them. Put yours in an environment variable rather than in the file you are editing, because the first script you write is usually the first script you paste somewhere public.
How do I make my first prediction market API call in one line?
Send a GET request with your key in the Authorization header. This works from any terminal with curl installed.
export PREDICTEFY_API_KEY="pk_live_your_key_here"
curl -s "https://data.predictefy.com/api/kalshi/fetchMarkets" \
-H "Authorization: Bearer $PREDICTEFY_API_KEY"
It asks one venue, Kalshi, for its live markets, authenticated with your key. The path shape is /api/{venue}/{verb}, so swapping kalshi for polymarket or limitless returns the same fields from a different exchange. That is what a normalized schema buys you: the URL changes, your parsing code does not.
If JSON comes back, the hard part is over. If it does not, check the header first, since it has to read Authorization: Bearer followed by the full key. Then check your request rate, because the free plan is documented at 60 requests per minute and a tight polling loop crosses that faster than most people expect.
What does a prediction market API return?
One normalized schema, whichever venue you named in the path.
That is the entire point of the path shape. /api/kalshi/fetchMarkets and /api/polymarket/fetchMarkets are the same call with one segment changed, so the parsing code you write for the first venue is the code you keep across 15+ of them.
Two things matter before you code against the response. Prices are venue local, so they compare only after normalization. And the order book is its own call: GET /api/{venue}/fetchOrderBook is keyed on an outcomeId, not on a market, because one market can carry several outcomes and each outcome has its own book.
| What you send | Value | Why it matters |
|---|---|---|
| Base URL | https://data.predictefy.com | Reads live here, apart from order placement |
| Auth header | Authorization: Bearer pk_live_... | One header, no signing, no wallet |
| Path shape | /api/{venue}/{verb} | A second venue is a one-word change |
| Market list verb | fetchMarkets | Tells you what is tradable right now |
| Order book verb | fetchOrderBook, keyed on outcomeId | Resting size instead of a quoted midpoint |
| Streaming | wss endpoint at /v1/stream | Replaces polling for continuous updates |
How do I call a prediction market API from Python or JavaScript?
Install the SDK, pin the exact version, and call the same verbs from your own code. Both packages are available in beta.
npm install @predictefy/sdk@1.0.0-beta.11
# List markets on one venue. The path shape is /api/{venue}/{verb}.
curl -H "Authorization: Bearer $PREDICTEFY_API_KEY" \
"https://data.predictefy.com/api/kalshi/fetchMarkets"
# The resting order book behind one outcome. Set OUTCOME_ID to an outcomeId
# from the list above. Swap the venue segment to reach any of the 15+ venues.
curl -H "Authorization: Bearer $PREDICTEFY_API_KEY" \
"https://data.predictefy.com/api/kalshi/fetchOrderBook?outcomeId=$OUTCOME_ID"
The Python package is predictefy on PyPI, currently 1.0.0b9, and pins the same way with pip install predictefy==1.0.0b9. Pin the exact version in both languages, because a floating range on a beta package moves under you.
The first call lists markets on one venue. The second asks for the resting order book behind a single outcome, which is the step most tutorials skip and the one that tells you whether a quote is real. For continuous updates, the wss WebSocket endpoint at /v1/stream replaces polling, and the free plan allows 2 concurrent streams.
Why does my first call return prices I cannot trade?
Because a midpoint is the average of two numbers, and one of them is often missing.
Predictefy measured 5,000 live Kalshi markets on 3 September 2026, reproducible from the public Kalshi API with no key. On 18.1% of them there was no bid at all. Nearly one market in five was publishing a midpoint that nobody was standing behind. On the books that did have two sides, the median spread was 5.1¢.
Liquidity is what separates a quote from a price, and 24 hour volume is the cleanest proxy for it.
| 24h volume | Median spread | Share quoting inside 2¢ |
|---|---|---|
| Under 100 | 8¢ | 7% |
| 100 to 1,000 | 7¢ | Not measured separately |
| 1,000 to 10,000 | 4¢ | Not measured separately |
| Above 10,000 | 1¢ | 69% |
That last column is measured at the ends only, 7% in the thinnest bucket and 69% in the busiest. The extremes matter when you pick a test market. The widest books were scalar economic markets, with KXUSCPIYEAR at 57¢ and KXFEDFUNDSYEAR at 42¢. The tightest were sports, with KXWC at 0.3¢. Point your first call at a liquid sports market and the API looks effortless. Point it at a CPI market and you will assume something is broken when the response is simply reporting an empty book honestly.
How do I go from reading prices to placing an order?
Order placement is a separate non-custodial service, and it runs per venue rather than pooled.
The paths sit under /v1/exec/{venue}/orders/... and cover build, submit, cancel, modify and refresh. Building an order is unmetered. Submit, cancel and modify charge credits. Every write takes an Idempotency-Key, which is what stops a retried request from turning into two positions.
POST /v1/exec/kalshi/orders/build
Idempotency-Key: 0f3c9a71-4b2e-4c8a-9f10-77d2a1c6e5b4
POST /v1/exec/kalshi/orders/submit
Idempotency-Key: 0f3c9a71-4b2e-4c8a-9f10-77d2a1c6e5b4
Build produces a signable order, submit sends it. They are deliberately two calls, so a dry run costs nothing and never slips into a live position. Orders on wallet venues are signed client side, and the hosted Kalshi lane takes your apiKeyId and privateKeyPem for that one request and then discards them.
If a strategy needs a leg on Kalshi and a leg on Polymarket, you place each leg on its own venue and you carry the execution risk in between. Anything that claims to fill both sides as one atomic trade is describing a diagram, not a system.
What does a prediction market API cost to start?
Nothing, at the tier most first calls belong on.
| Plan | Price |
|---|---|
| Free | $0 |
| Builder | $48.88 per month |
| Pro | $149 per month |
| Enterprise | From $2,500 per month |
The free plan is documented at 25,000 credits per month, 60 requests per minute, 1 API key and 2 WebSocket streams. Design your first script around those four numbers.
The arbitrage API comes with Builder at $48.88 a month. Cross-venue price comparison is the piece that costs the most to build yourself, because it means a separate integration per venue, and on Predictefy it is one call.
Can I make my first call without writing any code?
Yes. The MCP server runs with npx -y @predictefy/mcp under an MIT license, and it lets an AI assistant call Predictefy tools on your behalf.
Ask it for a market list, a spread or a live book in plain English, no script at all. Anything that moves money stays a deliberate second action by you.
Frequently Asked Questions
How do I get a prediction market API key?
Create an account on Predictefy and generate one. Keys carry the pk_live_ prefix and travel in an Authorization: Bearer header, so store yours in an environment variable rather than in code. The free plan includes one API key. No funding, wallet connection or venue account is needed to read market data.
Is there a free prediction market API?
Yes. The Predictefy free plan costs $0 and includes 25,000 credits a month, 60 requests per minute, 1 API key and 2 WebSocket streams. That is enough to make real calls against live books across 15+ venues, and Builder adds the arbitrage API at $48.88 a month when you want it.
What does a prediction market API return?
Normalized market data from whichever venue you named in the path, in one schema shared across 15+ venues. Order books come from a separate call, GET /api/{venue}/fetchOrderBook, keyed on an outcomeId rather than a market. Read the bid and the ask rather than the midpoint, because the midpoint is often not tradable.
Do I need to code to use a prediction market API?
No. The MCP server, installed with npx -y @predictefy/mcp and MIT licensed, lets an AI assistant pull prices for you in plain English. Writing code buys you scheduling, alerting and custom logic, but a first look at live prices across venues needs no script at all.
Why does my prediction market API call return 501?
A 501 means the venue you named has no public feed for that verb. The documented case is a trades tape on a venue that does not publish one, which is a fact about the venue rather than a broken call. Design around it: read markets and books from the data API, and check GET /api/{venue}/has to see which verbs a venue serves.
How do I stream live prediction market prices instead of polling?
Use the wss WebSocket endpoint at /v1/stream rather than looping GET requests. Streaming pushes book updates as they happen, keeps you under the documented 60 requests per minute limit, and gives you fresher prices. The free plan allows 2 concurrent streams, enough to watch two venues side by side.
Try It With Predictefy
Make the call, then make it useful. Compare one event across 15+ venues, the widest coverage of any cross-venue scanner, in the Arbitrage Scanner, wire the same data into your own code with the SDK, or read the full endpoint reference in the API docs. Reads start free, and every gap it shows you is qualified against a live order book rather than a midpoint.