How much to charge for an API integration
How much to charge for an API integration comes down to one question: what does it cost this business that two of its systems do not talk to each other? To the client, an integration is not code that calls an endpoint. It is the end of someone copying orders from the store into the accounting tool, or leads from a form into a spreadsheet, and the end of the mistakes that come with it. Price the build on a share of that value, add lines for each system, the sync rules and the error handling, and quote a monthly plan for upkeep. Do not price it on endpoints or on hours.
Integrations are good work to sell with Claude Code because Claude reads API docs quickly and a first working connection often comes together fast. That is also the trap. The demo works the first time you run it, so the job looks nearly done. The real work is everything the demo skips: expired logins, records that fail halfway through, duplicates when a sync runs twice, limits on how many calls you can make, and the day the other company changes its API. Price the happy path and you will do the rest for free.
Check whether a ready-made connector already does it
Ask this before you quote. Many popular tools already connect to each other through a built-in integration or a no-code connector. If one does the job, tell the client. It costs you this build and earns you the next one.
A custom integration earns its price when the ready-made option cannot do what the business needs. Fields that have to be mapped or transformed in a way the connector does not support. A system with no ready-made connector at all, like an in-house app, an industry-specific tool or an old database. Volume or timing the connector cannot handle. Rules like "only sync paid orders over a certain size, and flag the rest for review." When you hear those, you are pricing their specific way of moving data, and that is where the value sits.
The CCC Integration Quote
Five parts of an API integration quote
| Part | What it prices | Question to ask the client |
|---|---|---|
| Base build | The manual work, delays and errors it removes | Who moves this data by hand today, how often, and what goes wrong? |
| Each system | Access, authentication and learning each API | Which systems are involved, and who has admin access to each? |
| Sync rules | What moves, which direction, how often, and who wins a conflict | If the same record changes in both places, which one is right? |
| Error handling | Retries, alerts, logs and a way to replay failed records | If a record fails at 2am, who needs to know, and how? |
| Keep plan | Monthly checks, fixes and API changes | What happens to the business if this quietly stops for a week? |
Base build. Work out what the gap costs: hours a week someone spends moving data by hand, what that time is worth, and what a wrong order, missed invoice or out-of-date stock count costs when it slips through. Price the build at a fraction of one year of that value, so the client can see it pay for itself.
Each system. Every API is its own small project. Some have clear docs, a test environment and simple keys. Others need an approval process, a partner account or an admin on the client's side who takes a week to answer. Read the docs for each system before you quote, and price each one on what you find, not on the one you connected last month.
Sync rules. This is the line clients do not know they are buying. One-way or two-way? Real time or every hour? What happens to records that already exist? Which side wins when both change? Two-way sync is a much bigger build than one-way, so make the client choose on purpose and write the answer down.
Error handling. An integration that fails quietly is worse than no integration, because people stop checking by hand. Price retries, an alert to a named person, a log the client can read, and a way to re-send records that failed. This line is what separates a demo from something a business can rely on.
Ask these before you quote
- Show me the process by hand. Watching someone move the data once tells you the real fields, the exceptions and the value faster than any spec.
- Who owns the accounts? API keys and logins should be in the client's name, created by their admin, not tied to your personal account. How to hand off a Claude Code project covers the checklist.
- How much data, and how often? A few records a day and a full import of years of history are different builds.
- Is there sensitive data involved, like payments, health or personal details? That raises the bar on access, logging and where the code runs.
- Does their own app need a new API built first? If yes, that is a separate line, and how to build a REST API with Claude Code shows what goes into it.
More questions that save a bad quote are in client discovery questions before you quote.
Always quote the Keep plan
An integration depends on systems you do not control. The other company updates its API, retires an old version, changes a field name or tightens its limits. Passwords and tokens expire. The client adds a new product type or a new field. Any of these can stop data moving, and often nobody notices until a customer or the accountant does.
Quote a monthly plan in the original proposal. Say what it covers: checking syncs run and errors are cleared, renewing access, updating for API changes, and small changes like a new field. Say what it does not cover: new systems, new directions of sync and new features, which are quoted separately. How to price a maintenance retainer covers the structure.
How to present the integration quote
- Lead with the outcome in their words. One line on no more retyping orders or chasing out-of-date numbers, then the price.
- Itemize it. Base build, each system, sync rules, error handling, then the Keep plan. Itemized quotes get trimmed, not rejected.
- Gate payments on proof. A deposit to start, a payment when real records move correctly in a test run, and the final payment after it has run on live data. How to structure milestone payments for an AI project covers the schedule.
- Write the sync rules into the proposal. A short list of what moves, which way, how often and who wins a conflict, signed off by the client, ends the "it should have updated that" argument before it starts.
And skip hourly. Claude Code makes the build fast, so hourly pricing turns that speed into a pay cut. I covered why in why I stopped charging hourly for AI builds. If the client also wants a place to see and manage the synced data, how much to charge for a dashboard and how much to charge for a CRM cover those lines.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
How much should I charge for an API integration?
Price it on what the gap between the two systems costs today: manual data entry, delays and errors. Charge a fraction of one year of that value for the build, add lines for each system, sync rules and error handling, and quote a monthly plan for upkeep.
Should I charge more for a two-way sync?
Yes. Two-way sync means deciding which side wins when a record changes in both places, and handling loops and duplicates. It is a much bigger build than one-way, so put it on its own line and let the client choose it on purpose.
What is the difference between an API integration and an automation?
An API integration connects two specific systems at the code level so data moves between them reliably. An automation is usually a chain of steps across several tools triggered by an event. Many projects mix both, so itemize each part.
Should I charge a monthly fee for an API integration?
Yes. The other system's API will change, tokens expire and the client's needs grow. A monthly plan covers checking syncs, clearing errors, renewing access and updating for API changes.
Should I charge hourly for an API integration?
No. Claude Code makes the build fast, so hourly pricing punishes you for that speed. Price on the value of the work it removes, with each part itemized.
Last reviewed by Duncan Rogoff on October 13, 2026
