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 arbitrage API is free, so cross-venue price comparison costs nothing to try.
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.3# List markets on one venue. The path shape is /api/{venue}/{verb}.
curl -H "Authorization: Bearer $PREDICTEFY_API_KEY" \n "https://data.predictefy.com/api/kalshi/markets"
# The same call reaches any of the 15+ venues. Swap the venue segment,
# nothing else about the request changes.
curl -H "Authorization: Bearer $PREDICTEFY_API_KEY" \n "https://data.predictefy.com/api/polymarket/markets"The Python package is predictefy on PyPI, currently 1.0.0b2, and pins the same way with pip install predictefy==1.0.0b2. 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-77d2a1c6e5b4Build 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 are signed client side and there is no generic server-side signing route, which means your signing material stays with you.
Two limits apply from day one. Order size is capped at 100 USD, and each key is capped at 1,000 USD per rolling 24 hours. Nothing places a trade across two venues for you. 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.
One more limit worth stating plainly. fetchBalance on the hosted API returns 501 NOT_SUPPORTED, and stored history is proven for 11 venues rather than all 17. Better to learn that on call one than on deploy day.
What does a prediction market API cost to start?
Nothing, at the tier most first calls belong on.
| Plan | Price |
|---|---|
| Free | $0 |
| Builder | $49 per month |
| Pro | $249 per month |
| Scale | $999 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 is free. Cross-venue price comparison, the piece that costs the most to build yourself because it means a separate integration per venue, is the piece you are not charged for.
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. One design rule is worth knowing first: no single tool both builds and submits an order. 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. The arbitrage API is free outright. That is enough to build a working scanner, test it against live books, and decide whether a paid tier is ever needed.
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 NOT_SUPPORTED means that verb is not served on that route. The documented case is fetchBalance on the hosted API, which is unsupported rather than broken. Design around it: read markets and books from the data API, and keep anything that depends on account state out of your first script.
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.