The ladder redrawn, greyhounds from our own results, and a horse that is not its entry code

Issue #5

This one is early. Issue #4 went out on Thursday; the four days since it carried more change than most full weeks, so rather than hold it to Thursday, here it is on Monday. What changed: which plan sells what, and the cutover rules that keep every existing key whole; team keys, per-key caps and overage on the commercial tiers; greyhound results rebuilt on our own collection for every state; a stable horse identity across meetings; in-place prorated upgrades and promotion codes that apply themselves; and MCP 0.3.0. Everything in here shipped between Friday morning and Monday 11:00. Several of the new things have no customer usage yet and say so.

The ladder, redrawn

• What each plan sells changed on Sunday night. Plus (A$49, 140,000 credits) is now the model-builder tier: the permanent closing-line archive, bulk price-path exports in CSV and Parquet, webhooks, and a new POST /v1/racing/clv. Standard (A$29, 75,000 credits) keeps everything else and serves the closing-line archive over a rolling 90-day window; the window is stated on every archive response in X-Archive-Window-Days, on JSON as well as CSV. Business (A$99) gains IP whitelisting. The pricing page, the FAQ, the terms and llms.txt all render the same ladder from one source.
• Every existing key keeps what it had. A Standard key created before 22:00 Sunday 20 September keeps the full archive, price paths and webhooks, for as long as it stays in use, through upgrades and downgrades. The gate reads the key's creation time, not the plan, so nothing you were already calling now answers 403. The same rule, with its own cutover of 12:00 Monday, applies to runner-level betslip deep links, which now start at Plus for new keys: betslip_win_url, betslip_place_url and betslip_app_only on next-to-go and changes, betslip_url on best-odds quotes, stripped at serve time so a cached response never leaks them. Routes exist for four books: Unibet, TAB, Ladbrokes and Neds. Monday's 09:00 canary passed Unibet and failed TAB (the slip renders, the runner is missing), so TAB's fields are null until a run passes. Ladbrokes and Neds open the app, not the browser, and are not tap-tested.
• POST /v1/racing/clv, Plus and above, 5 credits: send up to 200 bets and get each one scored against the closing line, as the named book's close or the market best or median, with the CLV percentage, whether you beat the close, the result, flat-stake profit and the aggregates. It is the calculation most model builders were doing by hand from the archive.
• Unlimited is now called Scale. It carries 5,000,000 credits a month and a 402 at the cap, and a tier that stops is not unlimited. Display only: the plan key in API responses is still unlimited, every gate and Stripe mapping is unchanged, and older changelog entries keep the old name. Two keys were on it and neither has a subscription, so nobody's invoice changed.
• The Most popular frame moved from Standard to Plus on Friday. That was a decision about where new customers should land, not a measurement: Standard holds 25 of the 35 paying subscriptions today and Plus holds two.

Team keys, per-key caps, and overage that carries you

Asked by a customer running one integration for several clients who wanted to hand each one a key and a budget, and two commercial customers who asked what happens on the last day of the month when the pool runs dry.

• Several keys on one account and one credit pool. Business mints 3, Platform 5, Scale 10, Enterprise 25, the primary key included. POST /v1/keys/team mints, GET /v1/keys/team lists each key's calls and credits this period beside the pool balance, PATCH sets a label or a cap, DELETE revokes and keeps the history. All four are free calls and only the primary key can make them. Charges land on the pool; the usage log keeps the calling key; whitelist, rate limit and last-used are per key. /v1/usage and /v1/keys/info carry the pool and the team.
• A per-key monthly cap turns the pool into something you can resell. monthly_cap at mint or by PATCH, between 1 and the plan's monthly credits, null to remove. A capped key is metered on its own row and then the pool; at its cap it gets a 402 that names the cap and the label and charges nothing, with X-Credits-Key-Used, X-Credits-Key-Cap and X-Credits-Key-Remaining beside the pool headers. Caps reset with the monthly reset. No customer has minted a team key yet.
• Business and Platform no longer stop at the allowance. Past 300,000 credits, Business keeps answering at A$0.60 per 1,000 credits up to 150,000 more, so the most overage can add is A$90; Platform at A$0.30 per 1,000 up to 750,000 more, at most A$225. Enterprise the same shape. Below Business, and on Scale, the hard 402 is unchanged. The ceiling is a share of the plan's grant, so a bonus or an override does not move it. While overage is carrying you, X-Credits-Remaining reads 0 and two new headers, X-Credits-Overage and X-Credits-Overage-Ceiling, say where you are; the 402 at the ceiling names the ceiling, the rate, how to switch it off and the tier that raises it.
• It is off for every existing key. Overage is on by default only for eligible keys created from 10:00 Tuesday 22 September. If you are already on Business or Platform, POST /v1/billing/overage switches it on and GET shows the state; /v1/usage carries the same object and credits_remaining_with_overage. The charge is added to your next subscription invoice as one line, computed at the monthly reset before the counters zero, with a ledger row and an idempotency key so it cannot be billed twice. The first invoice that can carry one is 1 October, and the billing step has not yet run against a real account. The at-cap email, when overage is on, says overage is carrying you rather than that you are out.
• Promises, stated in the terms. Section 4.1 now carries the overage figures, and the Business and Platform cards replace the words priority support with what they mean: on Business, email answered within one business day, Sydney time; on Platform, four business hours on a direct channel, feature requests scheduled first and a monthly call; on both, breaking changes only with 30 days' notice. The Stripe product descriptions say the same. Those support figures are commitments typed on Monday, not measurements of what has happened so far.

Bulk files, and a widget without our name on it

Asked by three customers in one week who wanted to show our prices inside their own product with nothing of ours visible, one of them through the request form.

• Pre-built dataset files. GET /v1/bulk/datasets lists them at no credit cost, Business and above. GET /v1/bulk/{dataset}/{period} serves a day (2026-09-20, Business and above, 20 credits) or a month (2026-09, Platform and above, 100 credits), as Parquet or gzip CSV, with a sha256 ETag so a repeat fetch of an unchanged file is a free 304. Five datasets: closing lines, price paths, results, acceptances and track conditions, built nightly at 02:30 Sydney from the same SQL and column contracts as the paged endpoints, so a column added to the endpoint appears in the file. Your withheld-books list applies. August's closing lines are 11 MB.
• A white-label odds widget, Platform only. That is the redistribution rung of the licence and the widget is that licence in code, so it is never grandfathered and Scale, which costs more, does not carry it; its card no longer says every endpoint. POST /v1/widgets creates one with your colours, your allowed origins, your link template with per-bookmaker overrides and an hourly fill budget; ten per account; the config is validated with a 422 that names the field. Embed https://puntersedge.online/widget/v1/<id>/racing, /racing-greyhound or /<sport>. Each fill costs the owner 2 credits for racing and 1 for a sport, and one render is cached for 60 seconds however many readers load it. Every refusal, whether no credits, an origin you did not allow, the budget, a revoked widget or the API being unreachable, renders Odds unavailable right now in your colours with HTTP 200, and the reason is only in an HTML comment and X-Widget-Status. The templates carry no PuntersEdge, no tracking parameter and no link home, and a test enforces that. Recipe, parameters, affiliate example and a CSP snippet at /widgets. It went live at 11:00 Monday; no widget has been created yet.

Greyhounds: our own results, every state

• Greyhound results, form and stats now come from our own collection, in every state. Issue #3 described that collection as report-only and Victoria only. On Sunday evening it became the source: Victorian tracks from 19:43, every other state from 20:19, and /v1/racing/greyhounds/form and /stats served from a store built on those results from 20:37. Data we collect and settle ourselves is data we can stand behind, extend and license, which is the point of the change.
• Where the results now come from. Victoria from FastTrack's result pages, hourly; every other state from Greyhound Racing SA's national result pages, one page per race, hourly, written only into empty fields and only when every placegetter the bookmakers reported matches its position. Each result says which: field_source is fasttrack or grsa. The first pass filled 292 Victorian and 653 other races back to the 13 September card. Over the seven days to Monday morning, 594 scraped races matched 594 of ours and 592 of 592 comparable fields agree with the bookmaker-fed placings; two are blocked pending. Fill by day since Friday: 133 of 137, 85 of 90, 110 of 111.
• Form and stats are served from a store of our own results, refreshed hourly, keyed on the dog's name; a grv: or grsa: reference is accepted as a filter, and the two registries are mapped where the same dog carries both (14 of 6,109 names on Sunday). An unknown dog is a free 404. Coverage starts at the 13 September card and the response says so. Runs now carry the measured columns the result pages print: first_split_s, second_split_s, weight_kg, pir and grade, where the source prints them: grade on every run, first split on 288 of 362 measured, weight on 295; Western Australia publishes no weight, and only FastTrack publishes position-in-running. Stats have no grade dimension yet, because stored runs are never rewritten and none of the older ones carry it.
• Ninety days of history is being swept in from the same pages at one request a second: New South Wales and Queensland are done (21,577 and 13,092 runs), South Australia started answering 429 mid-sweep on Monday morning, and Victoria, Western Australia, Tasmania and the Northern Territory are not yet swept. The store held 44,032 runs at 11:00 Monday, 23 June to 20 September, but a dog's history before 13 September is complete only for the two states done. 661 scratched-runner placeholders, a row of dots where a name should be, were purged from 389 fields and are now skipped. A dead-man watch checks the two collectors and the store refresh every 30 minutes and alerts only when more than twelve races two to six hours old are unfilled.

A horse is not its entry code

Asked by a customer joining form to results across meetings, who found the same horse under a different reference every time it ran.

• runner_ref on a thoroughbred is Racing Australia's code for that day's entry, not the horse. Measured on Monday over our own results: of 1,452 horses with two or more runs, 1,450 carried a different code on every run, and one horse carried five codes over six runs. Every document that called it stable has been corrected. Greyhound references are per dog and are unchanged.
• horse_ref, the form pe: plus the folded name, now sits beside runner_ref on results runners and placings, next-to-go, best-odds, the closing-line archive and price-path exports in JSON, CSV and Parquet; greyhound and harness rows carry an explicit null. It is derived at serve time, so nothing had to be migrated. None of 2,708 acceptance names or 10,092 result names carried a country suffix and none collided. The known weakness: a name can be re-registered about seventeen years after a horse retires.
• GET /v1/racing/horses/runs, every plan, 3 credits: one horse's record out of our own settled results, no contact with Racing Australia, so it answers when the form endpoint cannot. 10,092 runs from 31 August to 20 September, refreshed hourly; win_time_s is null because Racing Australia publishes none. It is the fallback the MCP form tool now names.
• The form store is keyed on the horse. A page fetched under any of a horse's entry codes now serves every later lookup of that horse (859 pages, 823 distinct horses, so 36 were duplicates), a name resolves to one horse, and the check for whether the horse has run since was matching the entry code, which meant a stored page could be served stale forever. Fixed.
• While Racing Australia's form wall is up, the API says so. Since 01:00 Sunday every fresh read of a form page has been answered with a human-interaction challenge, so the paced backfill has delivered nothing since, with 945 horses queued and 134 done. The backfill status route now reports it, with upstream.state, walled_since and walled_hours; the 503 text points at /horses/runs, which answers from our own results; and a watchdog pages after three hours walled with work queued. Customer-visible 503s on form: none Friday, 128 to four keys Saturday, 35 to two Sunday, none Monday by 11:00. The overnight pre-read of tomorrow's acceptances is next, once the wall lifts.

Upgrades, promo codes, and the demo endpoint

Asked by customers moving between tiers, and everyone who has been sent a code.

• Choosing another tier is now an in-place, prorated upgrade. A subscriber who picks a dearer tier on the pricing page is emailed a 30-minute signed link, sent to the address on the key, that moves the existing subscription up and charges only the difference for the rest of the period; the billing date does not move and the key does not change. A cheaper tier gets a downgrade message rather than a checkout, and only an account with no live paid subscription sees the checkout at all.
• Promotion codes at checkout. The hosted checkout has a code box since Friday, and since Monday a code carried in a pricing-page link is looked up and pre-applied, so a link from an email lands on a checkout that already shows the discount. A code that is unknown, expired or not yours falls back to the ordinary full-price checkout with the box, never an error. Verified on a fresh email: Standard at A$29 became A$14.50.
• Running out on the free plan now comes with an offer. The email a key gets on its first refused call after 1,500 credits carries 50% off the first month of any plan, first subscription only, code CAPPED50, no expiry. It fires once per key per calendar month. The 500K thank-you code from last Thursday, half price for the first month, is open until Thursday 25 September.
• /v1/demo/best-odds now compares Australian books only. The keyless demo had been taking the best price over every book we hold a reference feed for, offshore ones included, so its best_bookmaker and arb_exists could point at a price no Australian can take. Since Monday the playground and the landing pages that render it show the same market the paid endpoints always did.
• A paying-customer count is published. /v1/health/stats, no key needed, now returns paying_customers: distinct billing customers on active paid keys, floored down to a multiple of five, so the site says 35+ and will say 35+ until it is 40.

For the people building on the API

• puntersedge-mcp 0.3.0 is on PyPI as of Monday 10:48, 30 tools. It teaches the assistant that runner_ref is same-meeting only and to join on horse_ref; adds horse_runs; adds racing_clv, its first POST tool; and adds bulk_datasets and check_overage, both free reads. The greyhound stats tool no longer claims a grade dimension. The Postman collection is rebuilt with the team-key routes, 67 requests.
• Four official clients, said once. The homepage and /api named only the Python package; the TypeScript client, the MCP server and the Postman collection were reachable only from /developers. One line now lists all four with live versions, and the homepage resources strip links the playground.
• 73 landing pages were publishing the same code block. Measured by eight-word shingles over every page in the API sitemap: only 3 of 269 pages set their own example, so 73 rendered one hard-coded call. Now 30 use-case pages, 43 bookmaker pages and 62 of 81 single-axis pages carry a call specific to the page, and every one of the 191 examples was executed against the live API before publishing: 0 failed. Three were corrected on the way: since is required on /v1/racing/changes, direction on /v1/racing/movers is firming or drifting, and a price-history example carried a venue and date that no longer existed. Pages more than three-quarters identical to their nearest neighbour fell from 22 to 2, the two being this page and the latest issue's permalink, which now declares the relationship. The eight /compare pages are still 82% boilerplate and are on the list.
• A crawl of all 665 site pages on Friday morning found 12 pages in the sitemap that nothing linked to, 51 unreachable from the homepage, and 285 still carrying the retired tipping share image. After it: a press page with live facts, logos and a badge, a compare hub, real share cards, and redirects for the addresses people guess; one orphan, one unreachable, and a monthly link audit that runs itself on the third of the month. Its first run found 294 sitemapped pages, no orphans.
• The API changelog is current again, with 17 entries for Saturday to Monday; issues #2 to #4 of this devlog cover the days before that. The devlog email now has a button to the request form above Read on site. Most of what shipped this issue was asked for by email and in replies, and that still works; the form is there if you prefer a list you can watch.
• Say who you are. The daily named-caller report saw three new user agents this week, one making 2,342 calls on its first day with nine server errors we could then look at, and one anonymous caller sitting at its credit ceiling for 1,022 straight 402s. If that is you, the email you got has the code in it.

Plumbing, and what went wrong

• The host reboot promised in issue #4 ran at 03:31 Friday, in the gap before the first Australian race; the API and the worker were back in two minutes and one second.
• Email has headroom. Our provider's plan was upgraded on Monday, so there is no daily ceiling for a campaign to exhaust and login links cannot queue behind one. Since Friday: 56 transactional emails, zero failures. The overage checks, bulk files, team keys and widget were each probed end to end on the public host with throwaway keys before this was written, and the probe rows deleted.

Reply with anything you want on the list. The two largest changes this issue, greyhounds from our own collection and a horse identity that survives the meeting, make the racing data ours to stand behind and to build on, and both are stated at their real coverage rather than the coverage we would like. Write to hamish@punters-edge.com or use the feature request form.