Skip to main content
GET
cURL
Use this public ledger to check that a settled pick matches its recorded commitment. The hash covers the pick identity, market, backed side, price, and kickoff using sha256(canonical_json(payload) || nonce). Read commitment_version to choose the correct payload format. The payload and nonce become available after settlement. No API key or subscription is required, and every caller sees the same fields for an entry’s state. The ledger retains commitments for withdrawn picks. Removing a recommendation from current picks or the archive does not change its identity, proof bytes, or provider-owned settlement. For results and the running hit rate, use Pick of the Day archive.

​
The three states

The ledger has one entry per published pick, sorted by date and publication order, oldest first. Read state before processing an entry because each state has different fields. Sealed entries omit the public kickoff field to avoid identifying an unresolved game. Opened entries retain kickoff and the original proof payload; historical commitment bytes do not change. Pending uncommitted entries also omit matchup and category.

​
Commitment versions

Check commitment_version before verifying a committed entry. Version 1 uses the original payload with pick_rank. Version 2 replaces that field with the decimal-string pick_id and adds the integer version: 2. The version 2 payload has exactly 9 keys: backed_price, condition_id, kickoff, pick_date, pick_id, pick_outcome_index, pick_outcome_label, platform, and version. Historical version 1 payloads retain their exact bytes and hashes, and an uncommitted entry claims no commitment version. Refuse an unknown or missing committed-entry version instead of guessing its payload shape. To fetch one published entry by its stable identity, use Get a Pick of the Day ledger entry.

​
Key response fields

​
Verify an opened entry

  1. Take the bytes of the payload object exactly as you received them. Do not reserialize it.
  2. Append commitment_nonce, decoded from hex.
  3. Take the SHA-256 of that concatenation. It equals commitment_hash.
The payload is canonical JSON, served byte for byte as it was hashed. Its keys are sorted by UTF-8 byte value, it carries no insignificant whitespace, its decimals are strings at full stored precision, and its timestamps are whole-second UTC with a literal Z.

​
Errors

A 500 with error.code internal_error means one entry failed a consistency check, so the whole ledger is refused rather than served incomplete. A 503 with Retry-After means the database was unavailable; retry after that many seconds.

​
Example

​
What it does not return

  • The backed side of a live pick. A pick payload has little entropy, so publishing the nonce before the game would hand out the side.
  • A commitment written after kickoff. A pick that reached kickoff unsealed stays uncommitted for good.
  • The outcome inside the hash. The commitment deliberately covers the pick, not the result, which is why a corrected market can move resolved_at while commitment_hash stays the same.
  • Anything formatted for display. An entry changes only when the pick does, so a rewrite of the archive’s wording can never look like a broken proof.

​
Caching

Save the response’s ETag and send it in If-None-Match on your next request. If the ledger has not changed, the server returns 304 Not Modified with no body.

Headers

​
X-Query-Validation
enum<string>

Opt into strict query-name validation. The default is compatible: unknown names are ignored and reported in X-Query-Ignored. With strict, an unknown name returns 400 bad_request with error.reason unknown_query_parameter before the handler runs, including when its percent escape is incomplete.

Available options:
strict
​
If-None-Match
string

Conditional GET validator from a previous ETag. Matching values return 304 Not Modified with an empty body.

Response

Pick of the Day commitment ledger

​
object
string
required
Allowed value: "pick_of_the_day_ledger"
​
data
object
required

The commitment ledger: every published pick, ascending, in the state its commitment is actually in. The counts are derived from entries in the same pass that builds it.

​
meta
object
required