What a claude api integration changes, and what it must not change

A claude api integration on a support desk usually starts with a modest ambition: summarise a long email thread, classify an inbound ticket, or draft a first reply for an agent to edit. Those are reasonable ambitions. The problem is that the model output arrives in the middle of a workflow that already has an evidentiary role. Support records are read back in disputes, in refund decisions, in complaints escalated to a regulator, and occasionally in litigation. If a customer was told something incorrect and nobody can establish who or what said it, the organisation carries the consequence.

So the design question is not whether Anthropic Claude can produce a competent draft. It can, and that is the least interesting part of the work. The question is whether, eighteen months after go-live, you can take a single ticket reference and reconstruct: what text was sent to the model, which model version processed it, what came back, whether a person edited it, who approved the send, and what the customer actually received. If any link in that chain is missing, the audit trail is broken, and the fact that the output was good on the day does not help you.

It is worth being blunt about a common failure. Teams frequently store only the final reply, on the assumption that the model is a drafting tool like a spell checker and therefore not worth logging. That assumption holds until the output is wrong in a way that matters — a misquoted returns window, an invented policy clause, a commitment to a refund that was never authorised. At that point the distinction between 'the agent wrote it' and 'the agent accepted a draft without reading it' becomes the entire investigation, and it cannot be established retrospectively.

  • Assistive — The model drafts or summarises, an agent reviews and sends. Lowest risk, and the pattern most support desks should start with.
  • Classifying — The model assigns a queue, priority or product category. Errors are recoverable but they shape routing and SLA timers, so the classification and its confidence need to be stored.
  • Autonomous — The model composes and sends without review, typically on low-value, high-volume queries. Only defensible with tight topic scoping, an explicit escalation path and sampled human review after the fact.

The record you need to write on every call

Treat each model call as a transaction and write an immutable row before you use the result. Not after — before. If the write to your log store fails, the sensible behaviour is to fall back to the unassisted workflow rather than proceed with an unlogged inference. This is the same discipline applied to payment gateway calls, and for the same reason: the record is the only thing that survives the incident.

The Anthropic Messages API returns enough metadata to make this practical. Each response carries a request identifier, the model identifier that actually served the request, a stop reason indicating whether the output completed or was truncated by the token limit, and usage counts for input and output tokens. Capture all of it. The request identifier in particular is what you will quote if you ever need to raise a support query with the vendor, and it is trivial to store and impossible to recover later.

Alongside the vendor metadata, store your own. The prompt template identifier and version, the identifiers of the source records that were interpolated into the prompt (ticket ID, order ID, knowledge base article IDs), the operator or service account that triggered the call, and a hash of the fully assembled prompt. Storing the hash as well as the text gives you a cheap integrity check and a way to group identical requests when you are analysing behaviour across thousands of tickets.

Finally, close the loop on the human side. Record whether the draft was sent unchanged, edited, or discarded, and store the diff where it was edited. Edit rates are the single most useful quality signal you will have. A drafting assistant whose output is rewritten seventy per cent of the time is not saving anyone time, and without the diff record you will be arguing about that from memory.

  • Request context — Timestamp, ticket reference, triggering user or service account, prompt template version, hash of the assembled prompt, and the source record IDs used.
  • Vendor response — Request identifier, resolved model identifier, stop reason, input and output token counts, latency, and the raw response body.
  • Human disposition — Sent unchanged, edited and sent, discarded, or escalated — with the edit diff and the identity of the person who decided.
  • Outcome linkage — The message ID of what was ultimately sent to the customer, so the log row and the customer-facing record can be joined in either direction.

Pinning the model and versioning the prompt

A prompt is code. It should live in version control, be deployed through the same release process as everything else, and carry a version identifier that is written into every log row it produces. Editing a prompt in a web console at four o'clock on a Friday, with no record of what it said before, is the fastest route to an unexplainable change in behaviour the following Monday.

Pin the model identifier explicitly rather than using an alias that resolves to whatever is current. Aliases are convenient in development and hazardous in production, because they mean your system's behaviour can change without a deployment on your side. Pin the version, record it, and treat a model upgrade as a change with its own testing cycle. The same applies to the API version header, which should be set deliberately rather than left to a default in whichever client library you happen to be using.

Keep generation parameters conservative and recorded. A low temperature and an explicit maximum token count reduce variance and make truncation detectable. If the stop reason indicates the output was cut short by the token limit, the correct behaviour is usually to discard the result and route the ticket to a human, not to send a reply that ends mid-sentence. Structure the output where you can — asking for a defined JSON shape and validating it against a schema before use turns a whole class of ambiguous failures into clean, loggable rejections.

Where the assistant draws on internal knowledge, make the retrieval step auditable too. If a vector store such as Pinecone is supplying candidate knowledge base passages, log the passage identifiers and similarity scores that were selected. When somebody later asks why the model cited a superseded returns policy, the answer is normally that the superseded article was still in the index, and you want that to be a two-minute lookup rather than a week of speculation.

Where the records live: the desk, the CRM and the boundary

Most support desks are not standalone. Ticket context comes from a CRM, and replies feed activity timelines that operations and finance staff read. If your records sit in HubSpot, the natural instinct is to write the model interaction into the ticket timeline as an engagement or note. That is fine for visibility, but it is not sufficient as an audit trail: timeline notes can be edited or deleted by users with ordinary permissions, and the object model is not designed to hold prompt text or token counts. The same caveat applies to a Zendesk Sell record, or to a Salesforce case history. Use the CRM for the human-readable summary and a dedicated append-only store — a database table with no update or delete grants, or an object store with versioning and retention locks — for the forensic record.

Data residency and processing terms deserve a decision made in writing rather than an assumption. The Anthropic API is a processor acting on your instructions, and the usual UK GDPR obligations apply: a lawful basis, a processing agreement, a record in your Article 30 register, and a retention period you can actually enforce. If your procurement position requires processing to stay within a particular cloud tenancy, routing the same model family through Amazon Bedrock is a legitimate architectural choice, though it changes the response metadata you receive and therefore the shape of your log schema. Decide this before build, not during acceptance testing.

Minimise what crosses the boundary. Support tickets are dense with personal data and occasionally with payment details a customer has pasted in against advice. A redaction pass before the call — stripping card numbers, bank details, national insurance numbers and, where the task allows, names — reduces both risk and the volume of data subject to your retention commitments. Log the redacted prompt, and log the fact that redaction ran and what it removed by category. If your retention policy says model interaction records are deleted after twenty-four months, make sure the deletion job exists and has been tested, because an untested retention policy is a statement of intent rather than a control.

Failure handling that does not quietly degrade

Model APIs fail in ways that differ from the ERP and courier APIs most integration work deals with. You will see rate limiting under load, transient overload responses during busy periods, and occasional latency that is an order of magnitude above the median. None of these are unusual and all of them need defined behaviour. Retry with exponential backoff and jitter for transient conditions, cap the total attempts, and make the fallback explicit: the ticket goes to the agent queue without a draft, flagged as such. Silent degradation, where the assistant simply stops producing drafts and nobody notices for a fortnight, is the outcome to design against.

Guard the commercial exposure as deliberately as the technical exposure. Token usage is metered, and a prompt that interpolates an entire ticket thread will consume far more input tokens than the same prompt against a summary. Set per-ticket and per-day ceilings in your own code, alert when the daily figure exceeds a threshold, and store token counts on every row so that a month-end cost query is a simple aggregation rather than a reconciliation exercise against a vendor invoice. Where volume is high and latency is not critical — overnight classification of the previous day's backlog, for instance — batch processing is materially cheaper than individual synchronous calls and should be considered at design time.

Be similarly disciplined about duplicates. If a desk automation retries a webhook, you do not want two drafts generated and two log rows written against the same ticket event. An idempotency key derived from the ticket identifier and the triggering event, checked against the log store before the call is made, costs very little and removes an entire category of confusing evidence.

Proving it works before go-live, and keeping it proven afterwards

Acceptance testing for a language model component cannot be a set of assertions on exact string equality, but it should not be a demonstration either. Build a golden set of fifty to two hundred real tickets, anonymised, with an agreed expected outcome for each — the correct classification, or a set of facts the draft must contain and a set it must not. Run the set before each prompt change and each model version change, and record the pass rate. It will not be one hundred per cent, and that is acceptable provided the threshold is agreed in writing and the failures are inspected rather than tallied.

After go-live, sample. A fixed percentage of assisted interactions should be reviewed by a supervisor each week, with the review outcome written back to the same log row. Combine that with the edit-rate data described earlier and you have a defensible quality regime: a documented pre-release test, a documented ongoing sample, and a complete record of every individual interaction. That is materially more evidence than most manual support processes generate, which is a point worth making to a nervous compliance function.

In our delivery model this work sits naturally across the four stages. Discovery and data mapping establishes which ticket types are in scope, what the redaction rules are, and where the append-only log will live. The fixed scope and estimate names the prompt templates, the model version to be pinned, the log schema and the acceptance thresholds. Build and acceptance testing runs the golden set. Go-live and handover delivers the code, the prompt repository, the log schema documentation and the runbook for what to do when the API is unavailable. A claude api integration built that way can be handed to an internal team and maintained by them, which is rather the point.

If you are weighing this up for a support function and want a view on scope before committing to anything, we are on 01303 883111 or hello@api-integrations.co.uk. The useful first conversation is usually about which ticket categories are genuinely safe to assist, not about the model.

Key points

  • Write an immutable log row before each model call, containing the prompt version, prompt hash, source record IDs, vendor request identifier, resolved model version, stop reason and token counts — and fall back to the unassisted workflow if that write fails.
  • Pin the model identifier and version the prompt in source control; aliases and console-edited prompts mean production behaviour can change without a deployment, which makes any later investigation guesswork.
  • Use the CRM timeline for human-readable visibility and a separate append-only store for the forensic record, then prove quality with a golden test set before release and weekly sampled review afterwards.