Claude API integrations that are checked before they write and capped before they bill
Claude API pipelines for extraction, classification, drafting and tool use over your own systems, with a person on every write, a second provider behind the first, an evaluation set and a spend ceiling set before launch.
This page is for buying a Claude API integration: a pipeline that sends documents, messages or records to Claude and does something useful with what comes back. Our Claude platform page covers the wider picture, including setting up Claude Code for a team. This one is the narrower job of building the pipeline, and the first deliverable is a decision about what the model may and may not decide.
The evidence, stated carefully. One production system, a trading group's ERP, reads supplier invoices with Claude, with OpenAI behind it as a second provider, and a person confirms every extraction before anything is written. Three more case studies list Claude in their stack: an estimating assistant, a solar business's operating system and a marketing platform. Their write-ups describe what the model is allowed to do and what the surrounding code does. They do not give model versions, volumes or an accuracy figure, and neither do we.
We are an independent studio. We build on Claude through its public API and hold no partnership, certification or endorsement from Anthropic. Where another model suits a job better we will say so, and the trading system already fails over between two providers.
Four jobs a Claude pipeline does, and where each has been built
The jobs are different enough that the controls differ. This is what the case studies show for each, and what they do not.
| Job | Where the model stops and code takes over | What the case studies show |
|---|---|---|
| Extraction from a document | The output is parsed against a schema, the arithmetic that can be checked is checked in code, and a person confirms on a screen beside the source. Only the confirmation writes. | Trading ERP: supplier invoices are photographed and read by a vision model, and the confirmation is what creates the purchase invoice and moves stock quantities, cost prices and the supplier balance. Estimating assistant: past proposals are extracted into a strict schema, code rebuilds the totals and flags any document that does not reconcile, and a person confirms before anything is stored. The estimating assistant is a working demo built on the client's own past proposals. |
| Classification and summarising | The model labels and summarises. Identifiers, links and titles come from the source record, so it has no way to invent them. | Marketing platform: in the news pipeline the model only classifies and summarises, and the link and title come from the feed. The write-up says it is live and runs on the AI app platform it was created on. |
| Drafting | Drafts go to an approval queue and never publish themselves. A claim that needs a source is blocked until one is verified. | Marketing platform: weekly drafts land in an approval queue, and approval is blocked while unverified funding or statistics claims remain. Estimating assistant: the scope text is drafted last, and what it mentions is checked against the estimate's lines. |
| Tool use over your systems | Read-only first, a few narrow tools, and writes that go through the same business logic and permissions as everyone else. | Solar operating system: the in-app copilot runs a tool-use loop over the live CRM, its writes call the same business logic as the REST API and sit behind a flag, and the public website chatbot gets exactly one tool, which captures a lead. The platform is live with the client team. The write-up does not say how heavily the copilot is used, and it says several integrations switch on only when their credentials are present. |
Five decisions, in the order we make them
Not a feature list. These are the choices that decide whether a pipeline can be trusted, taken in order because each one constrains the next.
- 01
What the model is allowed to decide
Write the rule down first. If it fits on one side of paper, it is code and not a prompt. The model gets the step where the input is a mess a rule cannot parse and the output is something a person can check. Applying that test removes more model calls than any prompt change would.
- 02
Constrain the output, then distrust it
Anthropic documents structured outputs that constrain a response to a JSON schema, so check which models support them today, then validate again in your own code. A schema keeps the shape right and does not make the content true, so values are checked against records you already hold. On the estimating assistant, code reconciles every line to its parent and to the subtotal, and a document that does not reconcile is flagged for review.
- 03
Put a person on the write
The model proposes and a confirmation writes. On the trading ERP the confirmation creates the purchase invoice and moves stock and balances, and every write is stamped with the acting user in an append-only log. For tool use the equivalent is that Anthropic's tool-use documentation has your own application execute a client tool and return the result, so the permission check sits in code you control and not in the prompt.
- 04
Fail over, and tell the failures apart
The trading scanner holds several keys per provider, advances on a rate limit, quota or authentication failure, then falls through to a second provider. Not every 429 is the same, though. Anthropic's rate-limit documentation says that when an organisation reaches its monthly spend cap the API returns a 429 with no retry-after header, and retries, including the SDK's automatic ones, keep failing until access resumes. Back-off suits a transient limit. A spend-cap error should alert a person and not loop. Limits are also set per organisation, so extra keys inside one account may not add capacity.
- 05
Log which prompt and model made each output
Keep the prompt version, the model, the validation result and who confirmed it beside the record, so a figure queried six months later can be explained. The model call is logged alongside the audit trail, not instead of it.
Six ways the bill is kept predictable
None of these is a figure. Cost follows tokens in and out, so we estimate it from a sample of your own documents and not from a per-document price quoted in the abstract.
A model matched to the job
Routing and classification rarely need the strongest model, while reading a creased photograph taken in poor light may. Test both on your own documents. Model lists and prices change often, so check Anthropic's current pages and not a table on ours.
Repeated context cached
Instructions, schemas and reference material sent on every call can be cached. Anthropic documents prompt caching as reducing processing time and cost for prompts with consistent elements, with cache reads costing less than uncached input.
Non-urgent work batched
Anthropic's Message Batches API processes requests asynchronously at a reduced cost. It suits a back-catalogue run overnight or an evaluation run, and does not suit a person waiting at a screen.
A budget per run, and no repeats
A token budget and a step cap on every run, and a document hash checked before the model is called so the same invoice is never processed twice because two triggers fired.
Usage logged per workflow
So a rise has a name. An alert on spend per workflow tells you which pipeline moved, which the account total never will.
A ceiling set before launch
Anthropic lets an organisation set its own spend limit and configure limits per workspace, and a new organisation may start on lower limits than the standard ones. Check yours before a launch date and decide who is told when a limit stops the pipeline.
An evaluation set before the first prompt change
A small set of your real documents, including the ugly ones, with known-correct answers, run against every prompt edit and every model change. It takes an afternoon to build and turns 'we think the new prompt is better' into a comparison you can read. Anthropic's own guidance on building evaluations starts the same way: define measurable success criteria, then test against held-out cases.
What the case studies show here is narrow, and we would rather say so. The estimating assistant holds one real job out of its library, its price book and its knowledge layer entirely, and compares the draft with that quote section by section. No case study on this site states a measured accuracy for a model step.
For a new engagement the set is therefore the first thing we ask for. It also makes the model a setting and not an architecture, which is what turns failing over to a second provider into a configuration change.
MCP servers over internal systems, only when an agent must choose
Most pipelines do not need one. A fixed workflow with a model at one step, or a plain API call, has less to secure. An MCP server earns its place when an agent has to choose among several actions over your own systems and you want that access defined, limited and logged in one place. Our MCP article sets out how to tell which side you are on.
The only build of this on the site sits inside the solar operating system. The tool registry behind the in-app copilot is also exposed as an MCP server with an OAuth layer, so Claude can connect to it as a custom connector, and because its writes go through the same business logic as the REST API, the gates, permissions and audit log still apply. We have not published a standalone MCP server.
Where we start is one read-only server over one system, on staging or a copy, with three or four narrow tools and a log, and no tool that sends, pays or deletes. Anthropic's Claude Code documentation tells users to verify they trust each MCP server before connecting it and notes that servers which fetch external content can expose you to prompt injection, so everything a tool returns is treated as untrusted text.
Claude Code for the build, under review
We use Claude Code to build, with an engineer reading every change and tests as the safety net, and the code lands in your repository on your accounts. Anthropic's Claude Code security page states that you are responsible for reviewing proposed code and commands for safety before approval. That is the working assumption here and not a footnote.
To be exact about the evidence, the school ERP case study is a build done with Claude Code, reviewed as pull requests, with seven read-only review agents; it is not a Claude API pipeline, and we have not published a rollout of Claude Code to a client team. The staffing platform write-up says it was built with AI agents working in parallel, but it does not name the tool, so we do not offer it as a Claude Code case study. Our Claude Code development service page covers the build and the team set-up in full.
What an engagement costs and what moves it
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation, once we have seen the process, its exceptions and the systems involved. No case study on this site states a price or a duration, so the range is not attributed to any of them. Model usage is a running cost on top, and we estimate it from a sample of your documents.
- How much of the input is exception: the invoice that arrives as a photograph of a fax, the supplier spelled two ways, the credit note. Each needs a decision to automate, route to a person or refuse loudly.
- Whether the result goes to one system of record or to several that must agree.
- Whether the rules need a database underneath: a once-only guarantee, memory of earlier events, or an audit trail that outlives a platform's run history.
- Whether an evaluation set already exists or has to be built from your documents first.
When a Claude integration is the wrong answer
If the decision can be written as a rule, use a router, a lookup table or a few lines of code: it is faster, free per run and identical every time. If the data already arrives structured (an API, a CSV, an EDI feed), there is nothing for a model to read, and a Make or n8n scenario will move it for less. And if the accounting or CRM product you already pay for offers capture or drafting that handles your documents, use that first.
It is also the wrong last step wherever nobody will review the output, or a wrong answer cannot be undone. None of this is an argument for one provider over another. We are not tied to one model, the trading ERP fails over to a second provider, and where a different model fits better we will say so.
Where it has shipped
Related projects that were not this job
Here for the argument rather than as evidence of this exact work. Each one bears on a decision above, and the note says which.
- A fleet-telematics providerOrders that file themselves, and an SLA clock that never forgetsNot a Claude build, and the write-up does not say a model does the parsing. It is here for the rollout discipline we would use on any pipeline that acts: a shadow-mode flag and a go-live cutoff that log what the system would have done before it is allowed to do it, which is the safest way to introduce a model step that writes.Case study
- A UK event-staffing agencyA staffing platform that keeps its rules in the databaseOn staging and not live, and the write-up does not name the model. It describes document reading by a language model that pre-fills dates with a confidence score, flags doubtful reads and never overwrites what the worker typed or marks anyone verified, built and switched off until the client signs off the legal and data-processing position. It is here for that line between a model that proposes and a person who verifies.Case study
- Skofi OutreachSkofi Outreach: deliverability rules the database refuses to breakNot a Claude build. It is our argument for putting the rules that must never break in the database and not in a prompt or in application code, which is where any model-driven step that can send email or touch money should be fenced.Case study
Related reading
Claude API integration, specifically
No, and we will not claim to be. We are an independent studio that builds on Claude through the public API and uses Claude Code ourselves. We hold no partnership, certification or endorsement from Anthropic, and nothing on this site should be read as one. If your procurement requires a certified partner, raise it in the first conversation and not the last.
It depends on the job and on your documents, and the only honest way to choose is to run both on a sample of your own with an evaluation set behind it. We do not publish a ranking. The trading ERP uses Claude and OpenAI together, with automatic failover from one to the other. Because we treat the model as a setting and not an architecture, changing it later is not a rewrite.
By putting limits in before launch. That means a token budget and a step cap per run, deduplication so the same document is never processed twice, the cheapest model that does the job, cached context and the batch interface for non-urgent work, and usage logged per workflow with an alert on it. Anthropic also lets an organisation set its own spend limit, and a pipeline has to handle the error that follows when a limit is reached. We estimate running cost from a sample of your real documents and do not quote a per-document figure in the abstract.
Not as a first step. The model proposes and a person confirms, and the confirmation is what writes. For tool use we start with read-only tools, a short list of narrow ones, and no tool that sends, pays or deletes. Where writes are added later they go through the same business logic and permissions as any other user, as on the solar operating system, and a shadow mode that logs what the system would have done is a sensible way to introduce them.
Anthropic's API and data retention page says retained data is never used for model training without your express permission, and that retention differs by feature and by model. Zero data retention is available for eligible features if you arrange it with Anthropic. Terms change and this is not legal advice, so check the current ones for your plan before sending anything sensitive. We also scope what is sent, so the model sees the fields it needs and not whole records.
Yes, which is called prompt injection: text inside a document that tries to give the model instructions. It cannot be fully prevented, so the design assumes it will occasionally work and limits what that can achieve. The step that reads untrusted content has no tool that sends, pays or deletes, its output is validated against a schema and your own records, credentials are narrow, and a person confirms before anything leaves the system or changes the books.
Yes, when the job calls for one, which is less often than the current enthusiasm suggests. The one example we can point to is inside the solar operating system, where the copilot's tool registry is also exposed as an MCP server with an OAuth layer. We have not published a standalone MCP server. Our MCP article explains when a plain API call or a Make scenario is enough.
Most of our projects land between $5,000 and $10,000 (US dollars). Larger systems cost more than $10,000. That is a typical range, not a quote: we quote after a discovery conversation, once we have seen the process, its exceptions and the systems involved. What moves the number is the exception rate, how many systems must agree, whether the rules need a database underneath, and whether an evaluation set exists yet. Model usage is a running cost on top, estimated from a sample of your documents.
Sources
Statements about what a platform, regulator or provider says come from their own pages. Rules and limits change, so check the current page before you rely on one.
- Tool use with Claude · Anthropic (Claude Platform Docs)
- Structured outputs · Anthropic (Claude Platform Docs)
- Prompt caching · Anthropic (Claude Platform Docs)
- Batch processing · Anthropic (Claude Platform Docs)
- Rate limits · Anthropic (Claude Platform Docs)
- API and data retention · Anthropic (Claude Platform Docs)
- Define success criteria and build evaluations · Anthropic (Claude Platform Docs)
- Connect Claude Code to tools via MCP · Anthropic (Claude Code Docs)
- Security · Anthropic (Claude Code Docs)
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no