Skip to content

Vendorica for developers

Vendorica’s public API lets your own systems read the registers you keep in the platform — vendors, contracts, risks, evidence, the audit log — and file documents into them without anyone opening a browser.

Base URLhttps://api.vendorica.com/v1

Authentication — a bearer API key, issued from Settings → API keys in the app. Keys are organization-scoped and carry explicit scopes. See Getting an API key.

Responses — every JSON response is wrapped in the same envelope, so a client parses one shape:

{
"success": true,
"data": { },
"timestamp": "2026-08-19T09:41:12.004Z",
"requestId": "req_01J..."
}

Versioning — the version is in the path. Within /v1 the API is additive only: new fields, new optional parameters and new endpoints can appear at any time, and a client must ignore fields it does not recognise. A breaking change cuts /v2.

The public surface is deliberately narrower than the application. It is mostly reads, plus four write paths:

Area Read Write
Vendors list, get bulk import
Contracts list, get, documents, download upload a document
Controls list, get, mappings
Evidence list (cursor), get, download upload to a control
Risk registers list, get
Risk scenarios list, get create, update
Incidents list, get file an incident
Policies list, get, versions
Compliance posture, framework by code
Trust Center resources, access requests, subscribers, visitor tokens
Audit log list (cursor)
Outbound webhooks list, get, triggers, deliveries create, update, delete

If you need something that is not here, say so — the surface grows by customers asking for the specific thing they are automating, not by speculatively exposing the whole application.

The OpenAPI 3.1 document is generated from the running service’s route definitions, not maintained by hand, and a CI check fails the build if it drifts from what is mounted. The API reference in these docs is built from that same file — so if the reference says a field exists, the service returns it.