Interfaces · Claravine API
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.
Trusted by
Why the default way runs out
A standard your systems cannot query is a document. The value arrives when the thing creating a campaign can check the rules before it commits to them.
- Your campaign records are generated upstream, and someone re-keys them into the standard afterwards.
- You export the taxonomy on a schedule, so every system consuming it is working from a version that is already behind.
- The systems that create your campaigns have no way to ask what the rules are, so you find out they broke one after they did.
What you can build with it
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.
How it works
Two APIs, and the naming differs from the interface in one way worth knowing: what the product calls a Template, the API calls a Dataset, and what the product calls a Submission, the API calls a Transaction. The Data Standards Cloud API is a REST API focused on submissions — create them, read them back, and search across them. The Classification API is separate, and handles classification of content and creative assets.
What a request looks like
One call, posting rows to a template. Governance runs on the way in. The response is a transaction UUID you poll for status — Pending, Complete or Failed.
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 '{
"transactionName": "Q4 Retail Launch",
"fields": ["Campaign Name", "Channel", "Region"],
"rows": [["Q4 Retail Launch", "Paid Social", "EMEA"]]
}'
# 201
{ "transactionUuid": "d4df4b94-a9d2-4875-9680-2a81d2e69a45" }Access and permissions
- API keys are generated in the interface and carry exactly the permissions of the user who created them. Access is not a way around governance.
- Every submission is processed against the same governance rules as one made in the interface, and appears in the same activity log.
- Default rate limit is 100 requests per minute, reported back in
X-RateLimit-LimitandX-RateLimit-Remaining. A single request carries up to 1,000 rows. - Running on SOC 2 Type II infrastructure with multi-tenant isolation, SSO and MFA.
The same taxonomy, whichever way you reach it
These are not three products. They are three ways into the same governed taxonomy — the one your templates define, your approvals control and your teams already submit against. A change approved in the interface is the change the API returns and the agent works from. Nothing forks, and nothing has to be kept in sync by hand.
All-or-nothing
Source: Claravine API reference, Create Transaction
Documentation
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.
Frequently asked questions
Didn't find your answer? Bring your questions to a thirty-minute walkthrough with someone who has done this at enterprise scale — we'll show you, not tell you.
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.
See it against your own taxonomy
Thirty minutes with someone who has implemented this at enterprise scale.