Three products, one key, one identifier

Every event we currently serve, with the fields you need to match it: our id, the sport, the league, both team names, kick-off, and which markets we price for it. JSON by default, CSV on request.

Parameters

Response — events[]

# the mapping job: everything kicking off in the next 48 hours, as CSV
curl -s "https://api.foreline.io/v1/catalog/events?hours=48&format=csv" \
  -H "X-Foreline-Key: $FORELINE_KEY"

event_id,sport,league,home,away,starts,markets,updated_ts
1632737351,football,UEFA - Champions League Qualifiers,Shamrock Rovers,Ararat-Armenia,2026-07-28T19:00:00Z,moneyline|spread|totals,1785262578.971

# the same slice as JSON
curl -s "https://api.foreline.io/v1/catalog/events?hours=48" \
  -H "X-Foreline-Key: $FORELINE_KEY"

In CSV, markets is pipe-joined (moneyline|spread|totals) so a comma inside a league name never forces you to parse quoting rules. Values in examples are illustrative.

The same slice collapsed to unique leagues, with an event count and the next kick-off in each. Takes the same sport, hours and format parameters. Use it to check coverage against your own competition list before you map thousands of fixtures.

league,sport,events,next_start
Argentina - Liga Pro,football,4,2026-07-28T22:00:00Z
USA - Major League Soccer,football,15,2026-07-29T00:00:00Z

Request body

curl -s -X POST "https://api.foreline.io/v1/score" \
  -H "X-Foreline-Key: $FORELINE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"account_id": "a_7731",
       "bets": [{"event_id": 1632737351, "market": "ah", "line": -0.25,
                 "side": "home", "odds": 1.95, "stake": 120,
                 "placed_at": "2026-07-28T14:02:11Z"}]}'

Response

Reject codes

The alert journal, newest first, filterable with since and status. Alerts raised from your own prices are tagged to your key and are visible only to you — another Line Radar subscriber never sees your book. Poll it on your own cadence or take the same events over the stream.

This endpoint is a choice, not a requirement. You send the prices you are currently showing; we de-vig them, compare each against fair at the same rung, and write anything past your threshold into the same journal you already read from GET /v1/alerts. Nothing about your book is inferred from third parties — if you do not send prices, we do not have them.

Request body

{ "quotes": [
    { "event_id": 1632737351, "market": "spread", "line": -0.25,
      "price_home": 1.95, "price_away": 1.95 },
    { "event_id": 1632737351, "market": "totals", "line": 2.75,
      "price_over": 1.90, "price_under": 1.98 },
    { "event_id": 1632737351, "market": "1x2",
      "price_home": 2.10, "price_draw": 3.40, "price_away": 3.60 }
] }

• All sides of a market are required. Your margin has to be removed before the comparison means anything, and that needs both (or all three) prices. A one-sided row is rejected.
• Prices are decimal odds, exactly as you show them. We never ask for your fair price or your margin — we derive the margin from the prices themselves.
• The line must exist on our ladder for that event and market: the main line plus the rungs we publish around it. A line we do not price is rejected rather than approximated.

The handicap sign convention — read this one twice

line on spread is the handicap of the home team, and p_home rises as line rises — exactly as in surface.markets.spread.rungs[].line. If your book stores handicaps against the away team, or as a positive number attached to whichever side receives it, you must convert before sending. This is the single most common integration defect on this endpoint.

Worked conversion. Your trader posts “Ararat-Armenia −0.5” — the away team giving half a goal. That is home receiving half a goal, so you send line: +0.5, with price_home being the price on Shamrock Rovers and price_away the price on Ararat-Armenia. Send it as -0.5 and we will happily compare your price against a rung about 28 pp away and alert on a gap that does not exist.

Sanity check before you go live: pull GET /v1/surface?event_id= for one event, post the fair prices back as quotes, and confirm the response contains no alerts. A correctly wired integration produces a zero gap on its own numbers. Ladder values above are illustrative.

Response and reject codes

Cadence and the threshold

• Send a batch every 30–60 seconds. The underlying data moves once a minute at its fastest, so a tighter loop compares your prices against the same fair numbers. The quota class allows four batches a minute — double the recommendation, so one retry after a network blip never pushes you out of your window.
• One batch, many rows. Send your whole active book in a single POST rather than a request per quote; the batch limit is generous and the per-row rejects let you keep sending the rest while you fix a mapping.
• Nothing about a gap closing is lost. Send every active price each cycle, not only the ones you changed: an alert whose gap has closed is resolved as withdrawn only when we see the corrected price.
• alert_threshold_pp is a setting, not a statistic. It defaults to 2.0 pp and that default is not statistically derived — it is calibrated against your own feed during onboarding, and the response repeats that disclaimer every time so nobody downstream mistakes it for a measured constant. Ask us to change it and it takes effect without a restart on your side.