Changes to the codriver developer surface and to this documentation. Newest first.
Until now the only extension point was data: publish a feed, get pins on the map. Apps add a second one — a catalogue entry a driver installs on their account, which can extend either plane.
Nothing in this section is live yet. There is no catalogue, no submission form, and no install button on the account page. The contracts are settled and the implementation is being built against them, which is why the documentation is going up first; every new page carries a dated status note saying the same thing. This changelog gets another entry, with a date, when the surface actually ships — that is the one to trust.
What the platform is:
pins and custom_layer are the feed mechanism that already exists, surfaced in the catalogue. widget and notifications are new: your own web page, rendered in a slot beside the map. The two new ones are mechanically identical in v1 and differ only as catalogue intent.pins or custom_layer app does not create its feed. In this release there is no automatic joining: you register the feed through the ordinary feed flow and submit a catalogue entry pointing at it. Details.widget or notifications slot runs in a sandboxed cross-origin iframe on your origin. codriver never runs your JavaScript in its own page, and your page cannot read the driver's session, location, speed or heading. Nothing location-shaped is passed to a widget in v1. That is a permanent property of the design, not a v1 limitation. See isolation.context, carrying theme, units, uiSize, slot, size, device and the driver's config. It arrives on load, whenever your page posts ready, on any change to theme / units / density, and whenever your slot's rendered size changes — so pages must handle it repeatedly. uiSize is a density preference, not a scale factor: lay out against size, because the host has already applied its own zoom, and use uiSize for your base type size. A suggested scale — 10.5 + uiSize × 0.6 px — is published so independent widgets in the same car agree; it is a convention, not a rule the host enforces. An optional config field the driver left blank is omitted from config, never null. Contract.ready more than once is legal and is the supported way to ask for a fresh context, one answer per ask; and unknown context fields must be ignored, because later versions may add them.hidden attribute rather than unmounting, and an unchanged install is never re-created — but Chromium throttles timers in hidden frames, so a long-lived stream needs a resume mechanism rather than an assumption of continuity. Details.config_schema — at most 12 fields, keys matching ^[a-z][a-z0-9_]{0,31}$, with secret: true for anything that should be masked on the account page and kept out of logs. codriver renders the form and stores the answers. A secret value is still delivered to your page in full; secret governs the form and the logs, not the delivery.widget_url, required if and only if you declare widget or notifications. It is not website_url, which is your product page and is never framed.pending until a curator approves them, and resubmitting creates a new pending version while the approved one keeps serving — review is never an outage. New versions must stay backward compatible with the config drivers have already saved. Rules.cost field is disclosure shown in the catalogue; anything an app charges is collected by its developer, directly from the driver.New pages:
config_schema, the embeddability and performance requirements, designing for a glance, a local test harness, submission, review and versioning.The home page is reframed around both paths. Nothing about the feed protocols changed.
The pages you are reading are generated from a public repository:
https://github.com/codriver-io/codriver-developer-docs. Edits made here and
edits made there converge — the wiki commits its own changes back, so the
repository is the record of what this documentation has said over time.
Practically, for anyone integrating: you can read the source of any page, see
when a claim changed and why, and open an issue against a page that is wrong.
The three months of drift that the entry below describes happened because there
was no such record.
Both the production site and the staging one at developer.staging.codriver.io
follow the same repository, so a change can be read on staging before it lands
here.
This site had not been touched since May. Several pages described an integration shape that was never the one POST /v2/feeds actually gives you. Everything below is either a correction to the docs or a change to the service; both are called out.
lat, lng, radius and an opaque per-car parameter on every driver request, with a short-lived cache in front. That is not what a registered pull feed gets. codriver fetches your pull_url every pull_interval_seconds with no parameters, and expects a top-level JSON array. Pull protocol is rewritten; so is the walkthrough.properties key holding a coordinate array is stored, but no shape is drawn from it. The jam example previously implied otherwise. See entities and kinds.properties keys are read back by codriver and are stripped from anything you submit — today, disputed_until. Documented here.429 with a Retry-After header. The 5 000-entities-per-request cap is unchanged.pull_url must be https, on a public hostname. Plain http:// is now rejected at registration, as are IP literals and localhost / .local / .internal hosts. Your auth header is replayed on every poll and should not travel in clear text. Existing feeds are unaffected until you next change the URL. The same validation now also runs on PATCH, which previously skipped it.GET /v2/sources. The catalogue listed a feed's layer as soon as it was created. It now lists a feed only once a curator has approved it, which is what the docs always claimed.GET /v2/entities/nearby and GET /v2/sources: real parameters, response shape, rate limits, and the fact that CORS is not enabled.Six pages published: overview, entities and kinds, pull, push, the kind catalog, and a walkthrough.