Bring your odds workflow.
Test the fit before you switch.

1. Build a request for your workflow

Choose your parameters below. Your key stays in your terminal. This builder creates a command; it does not send an authenticated request or ask you to paste a key into this page.

export PARLAY_API_KEY="YOUR_PARLAYAPI_KEY"

curl -i -sS 'https://parlay-api.com/v1/sports/baseball_mlb/odds?regions=us&markets=h2h&oddsFormat=decimal&include_live=true' \
  -H "X-API-Key: $PARLAY_API_KEY"

Use the sport catalogue for other keys, the bookmaker catalogue for source identifiers, and the SDK and language examples once your first request works.

2. Map the endpoints, then check the data

The familiar request structure reduces integration work. It does not establish identical events, book coverage, identifiers, or historical records. Keep your existing provider's event IDs separate from ParlayAPI IDs.

The source API's request contract is documented in The Odds API's official v4 guide. ParlayAPI's current contract is in our docs and OpenAPI. Verify the endpoints you use instead of assuming an SDK supports a base-URL override.

3. Verify the coverage your project depends on

Explore our catalogue of 30+ sportsbooks, then verify the sources that actually return your required events and markets. Catalogue breadth is different from coverage on an individual request.

• Sports and books: compare actual returned fixtures and bookmaker keys for your selected markets. Check coverage and service status; source availability changes over time.
• Source types: sportsbooks, exchanges, prediction markets, and DFS pick'em feeds have different structures. An alias is not an additional independent source. Do not assume each one supplies the same market.
• Freshness: inspect timestamps and the include=verification fields where available. A fast HTTP response or stream does not tell you when a sportsbook last changed its price.
• Empty results and missing fields: handle [], absent requested markets, and nullable timestamps. Retain request IDs for troubleshooting.

Add features only after the core request works

Explore player props, historical data, and streaming as separate integration steps. Odds WebSocket and SSE access start at Business. Validate each endpoint's shape, pagination, source coverage, and credit cost.

Game-line history is available from 2005, with availability varying by sport and source. Player prop history includes 30M+ prop closing lines since 2022. Check your intended dates and markets before committing to a backtest.

4. Estimate usage before choosing a plan

A credit is not necessarily a request. Regional game-line requests use the selected market count multiplied by the selected region count. The request builder uses one region; selecting three markets plans for three credits per call.

For example, three markets in one region, polled once per minute for six hours, plan for 1,080 credits: 3 x 360. This is usage arithmetic, not a price quote or a guarantee that every poll returns data. Adding books, props, history, or other endpoints requires checking their billing rules separately.

On your authenticated odds call, read x-requests-last for the charged credits and x-requests-remaining for the remaining allowance. Use your dashboard and limits documentation to check resets and access. Caching and polling only the markets you use can reduce unnecessary calls.

Handle limits deliberately

Paid plans still have a request-rate safety ceiling. A temporary limit needs backoff according to Retry-After or the error body. Exhausted monthly credits need a reset or an appropriate plan change; retrying faster will not help. See the current rate limits and allowances.

5. Validate a representative slate

1. Get a free key and make the generated request. Confirm the HTTP status and inspect the actual event array.
2. Match the fixtures, markets, and source keys your project needs. Include both pregame and in-progress behavior if your workflow uses them.
3. Check price format, event IDs, timestamps, missing data, pagination, and errors in your client.
4. Observe actual credit charges over your intended polling schedule. Choose a plan based on measured use and needed features.
5. Run your integration against both feeds over representative conditions before changing the provider used by a running application.