Skip to content

Changelog

Changes to the /v1 API and to this documentation, newest first.

/v1 is additive: new endpoints, new fields and new optional parameters can appear at any time, and a client must ignore fields it does not recognise. Anything that would break a conforming client cuts /v2 instead — so nothing on this page below a Breaking label will ever require you to change working code.


Updated — Rate limits are lower. The per-client budgets are now 300/min reads, 120/min writes and 60/min on the binary upload and download endpoints, down from 1,200 / 300 / 120.

A client that honours Retry-After needs no change. One that paces on a fixed sleep calculated from the old numbers will start seeing 429 — read the budget from the RateLimit-* headers instead, which have always carried it. See rate limits.

The old figures were not sized from observed traffic; they were a comfortable default. If you are doing a bulk migration, ask us to raise the budget on your API client rather than pacing around the default — that override is what it is for.

Docs — A guide to importing vendors and contracts. Import vendors and contracts covers POST /v1/vendors/imports end to end — match keys, upsert semantics, LEI enrichment, and reading the per-row outcome — and is explicit that contracts have no create endpoint, so a migration plans them through the in-app importer instead.

Docs — Every documented response carries an example. All 281 response bodies in the API reference now show a worked example. Success examples are generated from the schema itself, so they cannot contradict the field list beside them; error examples come from the error class the service actually throws, so code and error are the literal strings you will receive.

402 and 409 deliberately carry no example — each maps to several codes, and showing one would document a code you may never receive. Their status descriptions carry the meaning instead.

Docs — These docs were published at developer.vendorica.com.

They went up at docs.vendorica.com first and moved the same day. That address no longer resolves and never had an audience; it is recorded here only so a link someone captured in those few hours has an explanation.


New — Incident reporting. POST /v1/incidents and GET /v1/incidents, GET /v1/incidents/{id}. Scopes incidents:write / incidents:read. DORA reporting clocks are anchored on the incident’s reportedAt, not on when the record was created, so a backfilled incident keeps its real regulatory deadline.

New — Controls, compliance, policies and Trust Center reads.

Endpoint Scope
GET /v1/controls, /controls/{id}, /controls/{id}/mappings controls:read
GET /v1/compliance/posture, /compliance/frameworks/{code} compliance:read
GET /v1/policies, /policies/{id}, /policies/{id}/versions, /policies/{id}/versions/{versionId} policies:read
GET /v1/trust-center/resources, /access-requests, /subscribers, /visitor-tokens trust-center-content:read, trust-center-access:read, trust-center-subscribers:read

New — The risk write half. POST /v1/risk-scenarios and PUT /v1/risk-scenarios/{id}, scope risks:write. Risk registers stay read-only.


Every entry here describes a change that shipped. An entry is written in the same pull request as the change it documents, which is the only way a changelog stays true — one written afterwards is written from memory.

Label each entry with what it does to a client that is already working:

  • New — an endpoint, field or parameter that did not exist. Safe.
  • Updated — behaviour of something that did exist, in a way a conforming client tolerates. Read it anyway.
  • Deprecated — still works, will be removed in a future major version. Always names the replacement and the earliest version it can disappear in.
  • Breaking — cannot appear under /v1. Reserved for a future major.
  • Fixed — the service now does what this documentation already said.
  • Docs — this site changed; the API did not.