How to Get Alerts for Prediction Market Arbitrage
The Short Answer
Trigger the alert on a live order book rather than a midpoint, and deliver it over a WebSocket rather than a cron job, because gaps close in seconds and an alert you read an hour later is history. Across 5,000 live Kalshi markets, 18.1% had no bid at all, so an alert wired to midpoints pages you about prices nobody will trade. The Predictefy arbitrage API is free, and the Free plan opens 2 WebSocket streams on /v1/stream across 15+ venues on one normalized schema, alongside 60 requests a minute on the REST side.
Key Takeaways
- 18.1% of 5,000 live Kalshi markets had no bid at all, which means a midpoint-driven alert is quoting a price that does not exist.
- On a Kalshi binary, NO_ask = 100 - YES_bid, so a market with no YES bid makes the NO leg cost 100 cents while a midpoint model still prices it below 100.
- Median spread on two-sided Kalshi books was 5.1 cents, from 8 cents under 100 contracts of 24 hour volume down to 1 cent above 10,000. Volume is your best spam filter.
- The arbitrage API is free. The Free plan carries 25,000 credits a month, 60 requests a minute, 1 API key and 2 WebSocket streams, which is one poll a second in total and why streaming wins past the first pair.
- An alert is not an order. Execution is a separate non-custodial service, orders are signed client side, and every write takes an Idempotency-Key.
Why do most prediction market arbitrage alerts arrive too late?
Because they are built on a schedule instead of an event. A cron job that runs every five minutes is not an alerting system, it is a report on what already happened.
Polymarket runs 5 minute, 15 minute and hourly Bitcoin windows, and the shortest heading reads "BTC Up or Down 5m". A five minute market can open and settle between two runs of a five minute loop, and even when a run does land inside the window you see that market exactly once. Kalshi is slower here: none of its 274 crypto series runs shorter than 15 minutes.
So the first decision is not which venues to watch, but whether your trigger fires when the book changes or when your clock ticks.
What should an arbitrage alert actually trigger on?
The live best bid and best ask, with the size behind each, on both legs at the same moment. Not the midpoint, not the last traded price.
Across 5,000 live Kalshi markets, as of September 2026, 18.1% had no bid at all. A midpoint needs two sides to average, so for nearly one market in five your scanner is inventing a number. Worse, on a Kalshi binary the legs are tied together: NO_ask = 100 - YES_bid. A zero YES bid makes the real NO leg cost 100 cents, while a midpoint model prices that same NO leg at 100 minus half the YES ask. The scanner books that difference as edge on a market that cannot be entered at all.
This is most common at thin prices. Under 5 cents, 41% of markets had no bid. In the 25 to 50 cent band, 0% had no bid. Cheap longshots are where a naive scanner finds its best looking opportunities, and where they are least real.
| What you trigger on | What it really is | How it fails you |
|---|---|---|
| Midpoint | An average of two quotes, one of which may not exist | Fires on the 18.1% of Kalshi markets with no bid, where the other leg costs 100 cents |
| Last traded price | A print from some earlier moment | Says nothing about who is quoting now |
| Best bid and ask with size | The current top of book on both legs | Fails you least, since it fires only when both legs can actually be filled at a size you named |
How do you watch Kalshi and Polymarket prices at the same time?
Two venues means two native APIs, two identifier schemes, two price conventions and two reconnect strategies. Most alert projects stall right there, before a single notification fires.
Predictefy collapses that into one connection. 15+ venues arrive on one normalized schema, and the cross-venue arbitrage surface is recomputed server side, so your client subscribes to the result instead of rebuilding it from raw books.
What this does
Opens the stream. Connect to wss://data.predictefy.com/v1/stream and authenticate with the same Authorization: Bearer pk_live_... header the reads API uses. A browser socket cannot set request headers, so if you are connecting from the browser, take the handshake from the API reference.
What this does
Subscribes you to cross-venue arbitrage on the open stream. You get a message whenever that picture changes rather than on a timer, which is the whole point. Take the exact subscribe message from the API reference, because it is the one detail worth getting from the source rather than from a blog post.
Is polling fast enough to catch an arbitrage gap?
For one pair, sometimes. For a portfolio of pairs, no, and the arithmetic is blunt.
The Free plan allows 60 requests a minute, one request per second in total, shared across everything you do. Watch 30 market pairs by polling and each one refreshes every 30 seconds at best, against a monthly allowance of 25,000 credits.
A stream inverts the economics. The server pushes when something changes, so a quiet market costs you nothing and a busy one does not blow your rate limit. Polling still has a job, just a narrower one: the confirmation step immediately before you act.
How do you set up a prediction market arbitrage alert?
Start with the REST call. It is the fastest way to see real rows and sanity check your filters.
curl --request GET \ --url 'https://data.predictefy.com/api/{venue}/{verb}' \ --header 'Authorization: Bearer pk_live_YOUR_KEY'
What this does
Asks for cross-venue arbitrage rows over plain HTTP. Every read is one authenticated GET against https://data.predictefy.com, in the shape /api/{venue}/{verb}, with your key in an Authorization: Bearer header. Take the arbitrage route, and the parameter that sizes a request to the number of contracts you actually intend to trade, from the API reference rather than from this page.
Once that returns rows you believe, the build order is short. Open the stream, subscribe to the arbitrage surface, and filter in your own code, since only you know your fees and your bankroll. Re-run the REST call before acting, because the gap may have closed in flight.
If you would rather use a package than raw HTTP, @predictefy/sdk 1.0.0-beta.6 on npm and predictefy 1.0.0b4 on PyPI are available in beta. Pin those exact versions, because the latest tag points at a beta.
Where should an alert bot run?
A polling bot can live almost anywhere. A streaming bot needs a process that stays alive, which rules out most serverless functions, since each invocation is capped at a maximum execution time.
Your laptop is fine to start. For an alert you rely on, you want the smallest always-on box you can get: a cheap VM, a container that supports long-lived workers, or a Raspberry Pi.
Two details will bite you. The Free plan gives 1 API key and 2 WebSocket streams, one running process plus a spare, not one per machine left open overnight. And reconnect logic is not optional: a bot that stopped receiving frames looks exactly like a market with no opportunities, so log a heartbeat.
How do you get the alert onto your phone?
Push is the easy part. A Telegram bot, a Slack webhook, an ntfy topic or a Pushover key, or a paging service for overnight escalation are each one HTTP POST from the process holding the stream.
The payload deserves your time. A lock screen gives you about one line, so lead with the decision: both venues, both legs, the edge in cents, the size that edge survives to, and the age of the quote.
Be careful with units. Kalshi volume is measured in contracts and Polymarket volume in US dollars. They are not comparable, and a notification that quietly mixes them will make you misjudge which side is thin.
How do you stop an alert bot from spamming you?
An unfiltered stream becomes unreadable within a day. The fix is a short list of gates, most of them straight out of market structure.
Require a live bid on both legs. That one rule removes the 18.1% of Kalshi markets with no bid, a group that includes the 41% of sub-5-cent markets in that condition.
Set a minimum 24 hour volume. Median spread on two-sided Kalshi books was 5.1 cents overall, but 8 cents under 100 contracts of 24 hour volume and 1 cent above 10,000. Below that floor, the spread eats the edge before you finish reading the notification.
Filter wide books. The widest measured books were scalar economic markets, with KXUSCPIYEAR at 57 cents. A book that wide looks like a standing opportunity, when it is really an absence of quotes.
Then the boring hygiene: a cooldown per market pair so one gap cannot page you twice in ten minutes, a rule that the gap persist across two consecutive frames rather than one flicker, and a minimum edge measured after fees.
Short dated crypto needs its own rule. Five minute Polymarket traded volumes seen were 18 USD, 78 USD and 229 USD, many at 0 USD, while hourly windows showed 8.4K, 10.1K, 12.5K and 46.6K USD. Alerting on five minute windows mostly means alerting on markets where nothing traded.
How much does an arbitrage alert bot cost to run?
The arbitrage API is free. The Free plan is 0 USD with 25,000 credits a month, 60 requests a minute, 1 API key and 2 WebSocket streams, enough for a working single-process alerter across 15+ venues. Builder is 49 USD a month, Pro 249 USD, Scale 999 USD and Enterprise from 2,500 USD, and those buy higher limits rather than access to arbitrage.
Two design choices worth knowing, both deliberate. Stored history is proven across all 16 served venues, so backtesting your thresholds is well supported wherever you trade. And the hosted read layer holds no venue credentials and never sees them, which is also why there is no generic server-side signing route: nothing here can quietly turn an alert into a filled order.
If you want the alert to lead into execution, that is a separate, isolated, non-custodial service at its own origin, with routes under /v1/exec/{venue}/orders/ for build, submit, cancel, modify and refresh. Orders are signed client side, build is not metered, and credits are charged on submit, cancel and modify. Every write takes an Idempotency-Key, which stops a retrying alert handler from sending the same order twice. Default caps are 100 USD per order and 1,000 USD per key per rolling 24 hours.
Wiring this into an agent? npx -y @predictefy/mcp runs the MIT licensed MCP server, where no tool both builds and submits an order.
Frequently Asked Questions
How do you monitor prediction market prices in real time?
Hold a WebSocket open rather than polling on a timer. Predictefy streams 15+ venues on one normalized schema at /v1/stream, and the Free plan opens 2 streams. The server pushes when the book changes, so quiet markets cost nothing and busy ones do not exhaust your rate limit.
How often can you poll a prediction market API?
On the Predictefy Free plan the ceiling is 60 requests a minute, one request per second across everything you run, against 25,000 credits a month. That is fine for confirming one opportunity before you act, and far too slow for watching dozens of market pairs. Stream instead.
Do you need a server to run a price alert bot?
For streaming, yes, you need a process that stays alive, because most serverless functions cap each invocation at a maximum execution time. A cheap VM, a container or a Raspberry Pi is plenty, since one socket and a filter loop is not a compute problem. Your laptop is fine for testing.
Can you get push notifications when an arbitrage opportunity appears?
Yes. Filter the arbitrage stream in your own process, then send one HTTP POST to a Telegram bot, a Slack webhook, a push topic or a paging service. Keep the message to a line: both venues, both legs, the edge in cents, and the size that edge survives to.
Does an arbitrage alert mean the trade is still there?
No. It means the gap existed when the frame was sent. Gaps close in seconds, so treat every alert as a candidate rather than a fill. Requerying the arbitrage endpoint for the size you actually intend to trade is the cheapest confirmation step you can build.
Can an alert bot place the trade for you automatically?
Only if you build that part yourself. Execution is a separate non-custodial service at its own origin, orders are signed client side, and there is no generic server-side signing route. Every write takes an Idempotency-Key, and default caps are 100 USD per order and 1,000 USD per key per rolling 24 hours.