Claravine API | Claravine

Your taxonomy, available to every system that needs it

Read templates, validate values and write submissions programmatically — so the systems that generate campaigns can conform to the standard without anyone opening a browser.

Create campaigns from the system that plans them

Submit records straight from your planning or workflow tool, validated on the way in. The name is generated from the template rather than typed into it.

Validate on the way in, not afterwards

Governance rules run against every submission. If any row fails, the whole submission moves to draft and no attached integrations fire — so a partial, half-governed batch never reaches a platform.

Keep downstream systems current

Read templates and their controlled vocabularies on demand, so a consuming system is never working from an export that has gone stale.

Move data the way your stack already does

Where an API is not the right shape, the same exchange runs over CSV and XLSX, SFTP, or scheduled export.

Datasets (templates)

List Datasets · Get Dataset Definition · Get Dataset Rows by Generated Pattern

Transactions (submissions)

Create Transaction · Create Transaction from UUIDs · List Dataset Transactions · Get Transaction Data · Get Transaction Status

Pick lists

List Pick Lists · Get Pick List · Update Pick List

curl -X POST https://api.claravine.com/v1/datasets/{datasetUuid}/data \
  -H "x-claravine-key: $CLARAVINE_KEY" \
  -H "x-claravine-secret: $CLARAVINE_SECRET" \
  -H "Content-Type: application/json" \
  -d '{\n        "transactionName": "Q4 Retail Launch",\n        "fields": ["Campaign Name", "Channel", "Region"],\n        "rows":   [["Q4 Retail Launch", "Paid Social", "EMEA"]]\n      }'

# 201
{ "transactionUuid": "d4df4b94-a9d2-4875-9680-2a81d2e69a45" }

All-or-nothing

If one row fails governance, the entire submission is held in draft and no integration runs. A partially-valid batch cannot reach a platform.

Source: Claravine API reference, Create Transaction

Endpoints, authentication, request and response shapes, rate limits and worked examples are public. There is an OpenAPI definition and an llms.txt index, so an AI assistant can read the reference directly.

What can the API do that the interface cannot?

Nothing, by design — it exposes the same objects and enforces the same rules. What it changes is who does the work. The interface suits a person creating a campaign; the API suits a system creating a thousand, or a workflow tool that should never require someone to open a browser.

Which API do we need?

The Data Standards Cloud API if the job is submitting, reading or searching campaign data against your templates — that is most integrations. The Classification API if the job is classifying content and creative assets. Availability of the Data Standards Cloud API is tied to your platform tier and is enabled by your CSM; the Classification API is a separate contract.

Can we build our taxonomy programmatically?

Yes. The Template API covers the structural side, so a taxonomy that is generated or maintained upstream can be created and updated through code rather than rebuilt by hand in the interface.

What if a system we run has no API worth using?

The same exchange runs over flat files — CSV and XLSX, SFTP, scheduled export. That is not a fallback so much as a recognition that some systems will never have a connector, and they still have to receive the standard.

Does API access bypass approvals?

No. A write through the API is validated against the same rules and recorded in the same activity log as one made in the interface, and it carries the permissions of the user whose key made it.

How does this relate to the MCP server?

MCP is a conversational interface for people working in AI assistants; the API is a programmatic interface for systems. They reach the same taxonomy and enforce the same rules. Most organizations end up using both, for different audiences.