Using the MVP Capping API for your own analysis

The API lets you query the same data the site shows: events, odds, model picks with their outcomes and closing line value, and model records. It is for your own analysis: rebuilding a record your own way, joining picks with data you collect, or tracking strategies in your own tools.

It is read-only. There are no mutations and no webhooks, so you poll it for changes. Republishing what it returns requires a commercial licence, which the developers page explains.

API access is included with the Edge and Quant plans. Create a personal key under Account, then API access, and send it as a Bearer token in the Authorization header of a POST to /graphql. Keep the key out of browser code and public repositories, and revoke it if it leaks.

Each plan has a per-minute and per-day quota, listed on the developers page. Going over returns a 429 with a retry-after header; wait for it rather than retrying in a loop. Queries are limited to seven levels of nesting, and introspection is turned off in production, so build from the documented examples.

Poll on a schedule that matches how often the data changes. Picks and odds change through the day. Final records change once a game is graded. Asking every few seconds for data that changes every few minutes spends quota for nothing.

Rebuild one strategy's record yourself. Pull its graded picks, then compute wins, losses, units and average CLV from the individual rows. Compare your totals with the Strategies board. If they match, you have a working pipeline and a check on our arithmetic. If they do not, find out why before building anything bigger.

Then go further: split the record by price range, by how long before the start each pick was posted, or by day of week. Those are questions the board does not answer, and the API is the way to answer them.

A first request needs only a URL, a header and a query. POST to https://mvpcapping.com/graphql with the header Authorization: Bearer followed by your key, and a JSON body whose query field asks for model records, for example each model's name, profit in units and win rate. The developers page has copy-ready examples in curl and JavaScript.

Start small, read the shape of the response, and only then widen the query. A request that asks for everything at once is harder to debug and more likely to hit the depth limit.

Store each response with the time you pulled it. Odds and picks change, and a record you rebuild later needs to know what the data said at the time. A simple table of picks keyed by pick id, with the price, line, result and CLV, is enough for most analysis.

Treat a pick's posted price as fixed once you have it. Grades and CLV arrive later, when the game settles and the closing line is captured, so update those fields rather than overwriting the whole row.

The API returns what we hold, including its gaps. A game with no splits from our sources has none in the API either. Picks from models withheld from public view are not returned, the same as on the site. Record that in any conclusion you draw.