pitch.apis.autos
The functions a dealer group's systems call.
Deal-jacket extraction, verification, deterministic deal math, contracts-in-transit tracking — called mid-deal by your systems and agents, at posted rates, with a receipt for every call. The licence, the sale, the F&I signature, the title work, and the customer stay with the dealer.
↓ scroll · arrow keys
Every car deal stops in the middle for work that is neither the sale nor the licence: pull the buyer's documents out of the jacket, verify what was stated against what was scanned, run the tax-title-licence math for the right state and county, chase what funding still needs. Today that work is back-office staff hours plus a chain of point tools — each priced by seat or by negotiation, none of it callable at the moment the DMS needs it, and none of it re-performable when a lender audit or a factory audit asks how a figure was produced.
The cost has a name every dealer principal already watches: contracts-in-transit. Every day a deal jacket sits short a stip, a signature, a payoff letter, or a lien release is a funded car the store has delivered and cash it has not collected. The chase work that ages CIT is exactly the work in this gap — and it was tolerable when humans drove every step. It breaks now, because the caller is increasingly a machine: a desking tool, a funding checklist, an agent acting for either. A machine cannot sit through a seat-licence procurement, and a price it cannot read at call time does not exist for it.
The contract is small enough to state in full. discover the catalog — typed schemas, posted rates, versions. describe one function's contract. estimate a call before making it — the estimate is binding for the quoted inputs. extract deal-jacket documents — driver's licences, insurance cards, payoff letters, odometer disclosures, trade titles, income and residence stips — into structured, typed records. verify identity, document authenticity, and stated-fact consistency across a deal file. compute deterministic deal math — payment and fee figures, state and county tax-title-licence calculations, trade payoff and equity — versioned so the same inputs always reproduce the same figures. track what a deal jacket is missing before funding — stips, signatures, lien releases, title work — and how long each contract has been in transit. inspect the receipts.
// illustrative product mechanics, not results
POST /invoke
{
"function": "compute.ttl@v4",
"program": "group-desk-2026",
"inputs": { "salePriceUsd": 38500, "tradeInUsd": 11200,
"state": "TX", "county": "Tarrant" }
}
// every call returns a receipt:
{
"receipt": {
"function": "compute.ttl@v4",
"program": "group-desk-2026",
"credential": "org:group/systems/desk-prod",
"rate": "cited from the public card",
"outcome": "ok"
}
}
Nothing changes silently underneath a deal: every function version carries a published deprecation schedule, and a receipt cites the exact version and the posted rate it settled at. Receipts are designed to be the one record the office funds deals against, the controller closes the books against, and an auditor re-performs from — the same discipline a lender's funding department already demands of the jacket itself.
The licence. The sale. The F&I signature. The titling and DMV filings. The customer. This rail extracts, verifies, computes, and tracks; it does not sell a vehicle, execute a retail installment contract, process a title, or move money. Any step a statute reserves for a licensed dealer or a licensed person belongs to the dealer's own staff, and the rail is built so that routing is explicit.
That boundary is the design, not a limitation. A rail that tried to absorb the licensed steps would become a competitor to its own customers; a rail that supplies functions into licensed deals is infrastructure to all of them at once — including to dealer groups who compete with each other. Neutrality is what the boundary buys.
Where the buyer's data goes is a contract term, not an appendix. A deal jacket is consumer financial data: dealers that arrange financing or leasing are financial institutions under the FTC's Safeguards Rule, and extraction and verification mean that data crosses into the rail mid-deal. The rail is built to be read as the dealer's service provider, never a second user of the data. Data is program-scoped like the credential that carries it, processed to execute the invoked function and produce its receipt, and never used to train models. Retention is bounded by the program's stated retention window, and subprocessors are disclosed on a published list before they touch a program's data — not discovered in an audit.
The regulatory frame is the FTC's own: the Safeguards Rule covers auto dealers that arrange financing or leasing as financial institutions, and it obliges them to oversee their service providers. The rail is designed to sit on the service-provider side of that rule — and the scope and data terms it commits to are stated in this record, ahead of any surface.
How each verification function family sits relative to FCRA when its output is consumed in credit decisioning — service-provider status on the dealer's own applicant data, never assembling third-party consumer data for furnishing across customers — is a legal conclusion, not a design choice. It is ratified by counsel per family and published as part of the capability contract before that family serves a credit decision; it is not claimed as fact here.
The control posture — access, retention, subprocessor management — is asserted as an audited fact when the SOC 2 Type I report is published, not before. Until then it is a design commitment, written into the contract where a compliance review can hold the rail to it.
The estate holds two automotive coordinates, and the line between them is ICP and motion, not territory. auto.dev is the data plane: decode, search, specs, value — and the transaction rails underneath Vin — sold to developers building products for the dealer market. Its customer is the developer; its motion is B2A2D. apis.autos is the functions rail: the deal-file work — extract, verify, compute, track — metered to the retail operator's own systems mid-deal. Its customer is the dealer group; its motion is B2A2B.
The two compose instead of competing: a deal-file function that needs a VIN decoded or a vehicle valued calls auto.dev's rails at the same posted card any third party pays — the estate's one-card doctrine applied to itself. A developer who lands here finds the data plane in one click; a dealer group that lands there finds this rail the same way.
The sibling data plane serves today: auto.dev's API, documentation, and rate card are public on the domain — no sales call between a developer and a working key.
| name | unit | covers |
|---|---|---|
| Extraction | per invocation | driver's licences · insurance cards · payoff letters · odometer disclosures · trade titles · stips, to structured typed records |
| Verification | per invocation | identity · document authenticity · stated-fact consistency across the deal file |
| Deterministic deal math | per invocation | payment and fee figures · state and county tax-title-licence · trade payoff and equity, reproducible per version |
| Deal-file tracking | per invocation | missing · stale · needs-a-chase, plus contracts-in-transit ageing across the funding lifecycle |
Automotive retail is the home of the per-rooftop negotiated contract, which is exactly why this rail refuses one. The caller is a system, so the price has to be readable at call time by the thing deciding whether to call. One card means the studio's own brands pay what a hundred-rooftop group pays — list price IS the arm's-length price, and third parties paying it are what makes that true. Every receipt cites the posted rate, so a group's controller closes the books against the same public card its compliance review audits agent spend against. Volume does not buy a different rate: on a mostly fixed-cost platform, volume improves our margin at the same card, and the card staying flat is what keeps the rail neutral between a single point store and a national group.
Per-invocation rates by function class. The structure is fixed — metered, classed by compute and latency profile, program-scoped; the figures publish when the card is live, and no figure is asserted before then.
Machine settlement over x402 / Mandate rails is the designed payment path. Until the first settlement clears on those rails, payment is by funded program balance drawn down per receipt.
Automotive retail volume swings with rates, inventory, and incentives, and a metered rail does not get to hide from it: per-invocation revenue rides the industry's deal count by construction. Three properties are designed against the shape. Metered-with-no-minimums is trough-shaped: when volume falls, a metered bill falls with it by itself — there is no seat count to renegotiate against a bad quarter, so the integration survives the trough that kills per-seat tooling. The catalog spans the deal's whole lifecycle: front-of-funnel troughs shift the calls toward the back of the deal — funding chase, title and payoff work, CIT tracking — where the per-deal burden does not shrink when the deal count does. The rail's own cost base doesn't ride the cycle: no licensed human supply and no inventory sits on this brand's books, so a volume trough compresses revenue, not viability.
The lifecycle-mix property is a design claim today, and this deck labels it as one. It is claimed as fact when a reported function mix shows funding-side volume holding through a front-of-funnel trough — not before.
This rail's scope boundary is not a lawyer's abstraction — it is the operating lesson of a national automotive retail marketplace, function by function.
Agents built by this estate's automotive team ran sales, BDC, and desking on rocketauto.com for about a year — the archived capture shows the national marketplace as it ran. What was not unstaffed — the dealer licence, titling, DMV processing, and F&I compliance — stayed with Rocket's licensed humans, and those humans were Rocket's.
The capability outlived the host it first ran under: vin.company is the consumer retail experience running on the family's rails today, and the deal flow a visitor walks through there is the transaction layer at work.
That split is this rail's blueprint. Sales, BDC, and desking ran unstaffed; the licence-side work did not, and was never meant to. What apis.autos inherits is the boundary, not the workload: the rail meters its own catalog of deal-file functions on the unlicensed side of the same line. Nobody drew that line on a whiteboard; a working national operation drew it, and the rail is that boundary, productized.
Primary motion is B2A2B: our functions serve a dealer group through its systems and agents — the desking tool, the funding checklist, the agents the group already runs — calling the rail mid-deal on the group's own behalf. Stated plainly for anyone who has lived a certified-DMS integration program: the callers are the group's own systems and agents at the edge of the DMS, not plugins inside a closed CDK- or Reynolds-class core; a certified DMS-adjacent integration pattern is one this rail earns and posts when it ships, not one it assumes. Secondary is A2A: external agents transacting with the rail directly, machine to machine, settlement included. The channel matches the motion — machine-readable discovery at the apex domain and position in the agent-discovery namespace, because a rail whose caller is a system is found the way systems look, not the way buyers browse.
A2A is the least proven motion in the estate and the largest one if it lands. It is claimed when the first external settlement clears, not before.
The functions on this rail — extraction, verification, deterministic deal math, deal-file tracking — are precisely the work that migrates Human → Agentic → Generative → Code. The statutory floor in automotive retail sits with the licence-holder, which is the customer; the rail itself carries no licensed-supply cost and no inventory, so its economics are software economics on a mostly fixed-cost platform, and margin improves with volume at an unchanged public card.
Calling-system count, invocation volume, and revenue. Not presentable until the reporting basis resolves; no figure appears in this deck before then.
in the agent-discovery layer, automotive retail functions should resolve to apis.autos the way automotive data resolves to auto.dev — the domain is the shelf position for machine callers
the only rail in the family whose sibling data plane (auto.dev) and consumer proof (vin.company) are already live in the same estate — composition at the posted card, not a partnership deck
a group that has funded a year of deal jackets against versioned receipts and one public card does not re-verify a new vendor for sport — the audit trail is the switching cost
posted rates let the rail serve competing dealer groups simultaneously; a per-rooftop negotiated vendor structurally cannot be the neutral default for a whole trade
Stated plainly: this deck precedes everything except the coordinate and the family it joins. apis.autos is a G4 projection of the studio's G3 stack — the function runtime (functions.do), API layer (apis.do), and data layer (database.do) — and none of this rail's own surfaces have shipped: no catalog of these functions, no card, no front door of its own. What the apex serves today is the sibling data plane — auto.dev's API gateway answers on this domain, posted below because it is live and one curl finds it. Every amber below is deliberate: the deck is built before the catalog, and says so.
The coordinate is held on purpose: RDAP shows apis.autos registered at Porkbun — the domain created 2021-07-24, held through 2027, and its registration record last changed 2026-07-23, in the same week the estate assembled the rest of the rail family's coordinates. Registrar and dates are publicly verifiable in RDAP.
What the apex serves today is not this rail: https://apis.autos answers with auto.dev's API gateway — a JSON discover catalog of the sibling data plane's endpoints (VIN decode, specs, listings, taxes, total cost of ownership), with signup and docs pointing at auto.dev. A live fact, verifiable by one curl, and stated here rather than papered over.
This rail's own front door does not exist yet: the apex currently fronts the sibling data plane, and until it is re-pointed to this rail's own catalog the two automotive coordinates share a surface the estate's rule says they must not. The first posted claim this brand earns is its own front door.
The catalog — typed schemas, posted rates, latency classes, versions — is the primary surface, designed so a system never needs an HTML page to find, price, or call a function. It is claimed when a machine can fetch it cold.
The rail is built to the Agent eXperience Protocol posture — discoverable, priceable, callable by machine. Conformance is claimed only when a cold conformance run is published.
The claim that matters: an external group's production stack, calling under its own program-scoped credential against a funded budget, reconciling funded deals from receipts. It posts when it has happened, with the receipt discipline as the evidence.
The contract precedes the code: this record is the front door today — read it, then bring one rooftop's deal flow to scope against it.
If this was forwarded to you: apis.autos is the demand rail into automotive retail operations — deal-jacket document extraction, identity and stated-fact verification, deterministic deal math, and deal-file and contracts-in-transit tracking, called mid-deal by a dealer group's systems and agents at posted public rates, with a receipt for every call. The licence, the sale, the F&I signature, the title work, and the customer stay with the dealer; the rail supplies functions into licensed deals and never substitutes for the licence. Every claim above carries its own state and evidence — including the many not yet earned; this brand is candidly pre-launch. If you run a dealer group's systems: read the contract. If you know who does: forward this.