Claude API integration

What Claude is good for in business software

Claude handles long text well, follows detailed instructions closely, reads PDFs and images, and calls tools that you define. Those four traits map to a short list of jobs that pay off: reading documents, answering questions from your own material, drafting replies for a person to approve, and operating other software through tools.

It is not the answer to every task. Rule-based logic, such as tax calculation or stock levels, belongs in ordinary code. The model's job is the fuzzy part: understanding a messy supplier email or a scanned form. Our compare page on the OpenAI and Claude APIs goes through the trade-offs, and we usually test two models on your own examples before choosing.

What we build with it

No project in our work section is built on the Claude API, so we do not offer a client case here. These are the builds we deliver on it.

• Document processing: read invoices, purchase orders, resumes or contracts from PDF and return structured fields. See AI document processing.
• Support assistants that answer from your help center and look up an order or booking through a tool call. See AI customer service.
• Research and summary tools that read a folder of reports and answer questions with quotes from the source.
• Agents with a small set of tools and strict permissions, described in AI agent development.

Worked example: matching purchase orders to invoices

A distributor receives supplier invoices as PDFs and must match each one to a purchase order. A clerk used to read both and type the differences into a spreadsheet. Here is the build.

1. Read the PDFThe invoice is sent to the Messages API as a document along with an instruction to return only the fields we list: supplier, invoice number, date, line items and totals.
2. Force a structureWe define the output as a tool schema so the model returns fields in a fixed shape, and our code rejects anything that does not validate.
3. Look up the orderA second tool fetches the matching purchase order from your ERP by number. The model never gets database access, only this narrow function.
4. Compare in codeQuantity and price differences are computed by ordinary code, not by the model. The model only explains a mismatch in plain words.
5. RouteClean matches post automatically. Differences go to a review screen with the PDF page beside the extracted values.

We measure the build on a held-out set of real invoices: how many fields were exact, how many needed correction and how many were flagged correctly for review. The pass mark is agreed before the pilot starts.

Gotchas worth knowing before you start

• max_tokens is required on every request. If it is too low, the answer is cut off silently, so always check the stop reason.
• Rate limits return 429 errors and an overloaded service can return 529. Use retries with exponential backoff and a queue, not an immediate retry loop.
• Pin the exact model version in production. A moving alias can change behavior on a date you did not choose.
• Prompt caching cuts cost and latency when a long, stable prefix such as instructions or a reference document repeats across calls. Cache lifetimes are short by default, so batch similar requests together.
• Tool-use loops need a hard step limit and a timeout. Without one, a confused model can call the same tool repeatedly.
• Long documents are not free. Send only the pages you need, and use asynchronous batch processing for overnight jobs.
• Do not put secrets in prompts. Keep keys in a server-side vault and give the model only what the task needs.
• Streaming through some proxies buffers the response until it finishes. Test the real deployment path, not just localhost.

Claude is also offered through cloud platforms. If your company standardizes on AWS, see our AWS Bedrock development page for that route.

Timeline

Smaller single-step features can be shorter, and projects with several systems to connect take longer. The fixed quote after our short call states which one applies to you.