API integration services for systems no ready connector reaches
Our API integration services connect your business systems through their interfaces, so data moves between them without anyone retyping it. Systems with a ready connector we wire up in a few days. This page is about the rest: an ERP installed on a server in your office, a warehouse system from 2014, an internal API that appears on nobody's list. We write the integration from scratch, with rate limits, pagination, token refresh and a queue for failed operations. And we keep it running when the vendor changes the API.
- 2 to 4 weeksfrom workshop to the first integration in production, tested on your real data
- 6 partswhat every integration needs so it never wakes anyone at night: authentication, rate limits, pagination, retries, error queue, monitoring
- EUR 3,500 netone week of workshop, after which you know what to connect, in which direction, and whether it is worth connecting at all
The problem
Why does an integration without a ready connector take longer than the demo promises?
A salesperson closes a deal in the CRM. Now someone creates the customer in the ERP, types the same details into the invoicing system, makes a contract folder on the drive, adds a project in the task tool and posts about it on Slack. Five systems, five manual steps, the same VAT number retyped five times. At thirty new customers a month that is dozens of hours of work and just as many chances to misspell a company name or put the wrong amount into the ERP.
A connector catalogue in an off-the-shelf platform solves this in fifteen minutes, as long as both systems are on the list. The trouble starts with the systems that are not on it: an ERP installed on a server in your office, reachable only from your own network, a warehouse system that came bundled with the building, an internal API written by a developer who left three years ago. Nobody built paged reads for you there, nobody counted the rate limit, and nobody worked out what happens when the token expires on a Sunday night.
Rate limits are not a matter of imagination, they sit in the documentation. Google publishes its own caps on request counts and batch sizes in the BigQuery quotas documentation, and every larger vendor has an equivalent page. Authentication works the same way. Tax and e-invoicing platforms across the EU issue their own tokens, run their own test environments and set their own access rules, and none of that fits a login and password field in a configuration wizard.
- The same customer lives in three systems and nobody knows which record is current
- The sync stopped on Friday and the company heard about it on Monday, from a client
- The integration was written by someone who no longer works here and nobody knows where it runs
- The vendor changed the API, the export died, and finance went back to pasting from a spreadsheet
Why now
What changed, so that a custom integration takes weeks instead of a quarter?
The systems that actually sit in B2B companies today have documented interfaces: HubSpot, Salesforce, Pipedrive, Shopify, WooCommerce, BaseLinker, Xero, sevDesk, Google Workspace, Microsoft 365, BigQuery. For many of them the entry point is already written up on its own page, for example the HubSpot integration and the BaseLinker integration. You no longer start from the question whether it can be done at all, you start from which fields move, and in which direction.
The second change is practical. We write less code of our own, because the runtime layer already exists: queue, scheduling, retries and logs come from n8n, Make or your own infrastructure, and only the part nobody built for us stays custom. That layer is documented openly, retry behaviour and error workflows included, in the n8n documentation. This is the difference between an integration written over a quarter and one written in two weeks.
The third thing is the question of sync state. Instead of reading logs, you ask an AI agent: did today's orders reach the ERP, how many records are sitting in the error queue, when did the price sync last run. BOND, our company AI agent, answers that in a sentence in 5 to 10 seconds. The same connections are what any AI integration runs on: an agent can only work with the data it can reach through an API.
What changes
What do you get beyond the connection itself?
We connect the system that is not on any connector list
If the system speaks REST or SOAP, we go in through the API. If it does not, there is still a file export over SFTP, a read-only view in the database, or a webhook the vendor can add on their side. Which order we try them in is decided in the workshop.
REST, SOAP, SFTP file, SQL database, webhook, ERP export: six ways in instead of one
Rate limits and pagination handled on our side
The integration reads data page by page and watches its own time window so it stays under the vendor cap. After an interruption it resumes from the last confirmed record, not from the top of the catalogue.
Paged reads, a last-modified marker, resume from the point of failure
The token refreshes itself
Access sits in one place, with least privilege as the rule. An OAuth token refreshes automatically, a static key has its expiry date recorded and an alert before it stops working.
An alert 7 days before a key expires, instead of a phone call from finance on Monday
A failure does not vanish and does not stop the rest
A failed call is retried 3 times with a growing gap. If it still does not go through, the record lands in the failed operations queue with the error text attached, not in the gap between two systems.
3 retries, then a review queue and a notification to a named person
Field mapping written down, not held in a developer's head
A customer in the CRM and a counterparty in the ERP are two different data models. We produce a mapping sheet: source field, target field, conversion rule, behaviour when data is missing. That sheet stays with you.
Units, VAT rates, currencies and date formats settled in writing, before the first line of code
An API change at the vendor does not stop your company
We record the API version and check response shape in monitoring. When the vendor changes a format or retires a field, you see it straight away, not after a week without invoices.
Response monitoring and a recorded API version, so a change shows on the day it happens
Proof
Do you connect your own systems this way?
Yes. The AI agent inside our founders' agency runs on more than a dozen systems joined through APIs, including ones that had no ready connector. Below is the scale of that work, together with what the number does NOT prove.
Built for ourselves. These are not client deployments but implementations inside the founders' own companies. We say so plainly, because proof you cannot verify is not proof.
JustBottheir agentJustIdea Agency, a performance marketing agency of around 30 people
- 23
- people from the company work with the agent
- 38
- systems wired in permanently
- 112
- processes run without a human
- 475
- thousand lines of the agent’s code
API integrations with the CRM, the task system, Google Ads, Meta, the SEO tool, Analytics, Search Console and the data warehouse. First commit 1 March 2026, today 23 people use it.
8 of 38 systems it works in
Google Ads
Meta Ads- HubSpot
- ActiveCollab
- Ahrefs
GA4
Search Console
BigQuery
- Before
- Client data sat in several systems separately. Pulling it into one place meant opening one panel after another and pasting into a spreadsheet, so the report was produced once a month, because more often than that nobody could face it.
- After
- The integrations feed the warehouse and trigger operations in the connected systems on their own, on a schedule and on events. People step in where something has to be decided, not where something has to be copied across.
64,903 operations in 30 days across systems joined by API, of which 29,854 ran without a human
And in your company
What if our system is old, or simply odd?
Four sentences come up most often when the integration has to be written from scratch, and this is how we answer them.
Our system has no API.
It usually has something we can use: a file export, a batch import, database access, or a web interface behind a token. We check that in the workshop, in the documentation and with the vendor. If there really is no way in, we say so plainly and look for a different place to automate, rather than promising an integration nobody could keep alive.
We already run an off-the-shelf platform and it works.
Good, and there is no reason to touch it. We write a custom integration only for the connections a ready connector does not cover, or covers without rate limits, pagination and error handling. Everything else stays where it is.
The vendor will not give us database access.
And they are right, because writing straight to the database bypasses the rules the application enforces. We work through the official API, or through an account with read-only rights to named views. The scope of those rights is written down, so it can be revoked later in one place.
We will not agree to testing on real data.
We test in three stages: first read-only, then writes into the vendor test environment if one exists, then writes in production on a narrow sample of tagged records. Every stage has a written rollback. We go to production because a test environment almost never carries your real edge cases.
- CRM
- HubSpot, Pipedrive, Salesforce, Zoho
- Finance and ERP
- Xero, sevDesk, Fakturownia, Comarch Optima, on-premise ERP systems
- Commerce
- Shopify, WooCommerce, BaseLinker, PrestaShop, marketplaces
- Team tools
- Google Workspace, Microsoft 365, Slack, Notion, ClickUp, Jira, Asana
- Data
- BigQuery, Google Sheets, GA4, SQL databases
- Integration layer
- custom API integrations, webhooks, n8n, Make, Zapier
What we settle on every integration, before the first line of code
Seven things decide whether an integration survives its first quarter. We collect the answers in the workshop and they stay in a document you keep.
| Part | The question we have to answer | What happens if you skip it |
|---|---|---|
| Authentication | OAuth token, static key or service account, and who refreshes it | the integration stops on the day the key expires, usually at a weekend |
| Rate limits | how many calls per minute the vendor allows and what we do after a rejection | the vendor cuts access for an hour and the data from that window never arrives |
| Pagination | after how many records we move to the next page and where we resume from | the first page loads, the rest of the catalogue is invisible |
| Direction and conflicts | which system is the source of truth when a record changed in both | two versions of the same customer overwrite each other in a loop |
| Field mapping | how we convert units, VAT rates, currencies and date formats | an invoice goes out with the wrong amount and the error surfaces at month end |
| Error handling | how many retries, at what interval, where a failed record lands | an order disappears between systems and nobody notices |
| API version | which version we call and how we learn it is being retired | a vendor update switches off your process without warning |
On the first integration we answer all seven questions. On the next ones it comes down to an hour, because the rules are already written.
How we work
The five stages of an API integration, from two separate systems to production
Every step ends with something you can judge before you decide on the next one.
Workshop and interface audit
We break the process into steps and check what we have to work with: API documentation, limits, versions, the authentication method, access to a test environment. With on-premise systems we also check whether they can be reached from outside at all, and on what terms.
Data contract
We produce the field mapping sheet and the decisions on sync direction, source of truth in a conflict, and frequency. This is also where the route is chosen: a custom API integration, a ready platform as the runtime layer, or both.
Pilot on real data
First read-only, then writes on a narrow, tagged sample. We look for the edge cases the documentation never mentions: duplicates, records with no VAT number, orders with items deleted from the catalogue, characters outside the Latin alphabet.
Production with monitoring
We switch on full volume together with monitoring, a failed operations queue and a notification to a named person. The old way of working stays available until the numbers from both routes agree.
Maintenance and vendor changes
After 30 and after 90 days we check what actually passed through the integration and what landed in the error queue. When a vendor changes the API or retires a field, we fix it on our side before the process stops.
Before and after
How the week changes for the person who watches the data
Before
- The same customer created by hand in three systems, from scratch every time
- The question whether it reached the ERP is settled by opening two panels
- A broken sync is reported by a client, not by the system
- How the integration works is knowledge held by one person
After
- A record is created once and appears in the other systems on its own
- Sync state is visible in one place, and an AI agent answers questions about it in a sentence
- A failed operation waits in the queue with the error text and clears on retry
- Field mapping and access rights are written down, so anyone on the team can make a change
The first records pass during the pilot week. Whether the integration is stable is clear after 30 days, whether it still fits the process after 90.
For the person signing this off
What an operations director gets out of it
You stop answering the question where the current data is, because there is one place a record is created and one rule by which it reaches the other systems. A broken integration stops being a discovery a week later and becomes a notification the same day.
The second thing matters in the board meeting and on the day a developer resigns. A custom integration usually ends up as knowledge held by one person. Ours ends up as a document: field mapping, scope of access, API versions, rollback procedure. That is what stays with you, including on the day we stop working together.
- Field mapping and conflict rules written down, independent of any one person
- Scope of access to each system described and revocable in one place
- A pilot on real data before full volume, with a written rollback
- Measurement at 30 and 90 days, so the decision to extend is made on numbers
What it costs
The workshop has a published price, the integration is quoted after it
The process workshop costs EUR 3,500 net per week, and runs from one to seven weeks. For a single integration one week is usually enough: the process is narrow and the work is writing down fields and rules. We quote the integration after the workshop, because only then is it clear how many systems are involved, whether they are documented, and whether the vendor provides a test environment.
Tool costs you pay directly to the provider: the automation platform, hosting, and the language model provider if an AI agent is part of the scope, where a query costs the provider roughly EUR 0.005 to 0.07. No margin from us on any of it. When the integration runs on your own infrastructure, you pay nobody for it.
Process workshop
EUR 3,500 net
per week, one week is usually enough for a single integration
A self-contained piece of work. It ends with a document that stands up without us and that your own developer could build from.
- Interface audit of both systems: API, limits, versions, authentication
- Field mapping sheet together with conversion rules
- Decision on sync direction and source of truth in a conflict
- A recommended route: custom integration, ready platform, or both
- Most popular
Workshop and integration rollout
Quoted after the workshop
scope follows from the number of systems and the state of their documentation
The option most companies choose. A working integration 2 to 4 weeks after the workshop, tested on your real data.
- Everything in the workshop
- Integration over API, webhook, SFTP or database, depending on what the system offers
- Rate limits, pagination, token refresh, retries, error queue
- Pilot on a tagged sample, then production with monitoring
- Documentation and handover to your team, rollback procedure included
Integrations and an AI agent
Quoted after the workshop
for companies that ask about data state several times a day
Everything in the rollout plus BOND, which answers questions about data from the connected systems in a plain sentence.
- Everything in the integration rollout
- An AI agent wired into the systems over the same APIs, answering in 5 to 10 seconds
- Alerts on a stopped sync and on records waiting in the error queue
- Agent rollout usually takes around 2 months, once the integrations run
The workshop ends with a document that stands up without us: field mapping, conflict rules and a rollout plan. If the workshop shows that a ready connector is enough, or that there is nothing worth integrating in this process, we say so plainly and the engagement ends there.
Frequently asked questions
What are API integration services?
It is the work of connecting two or more systems through their programming interfaces, so data moves between them without a person in the middle. Typical examples: a customer won in the CRM appears in the ERP, a shop order reaches the invoicing system, a stock level goes back to the shop. The service covers more than the connection itself: direction, frequency, field conversion rules and defined behaviour on failure. It differs from a ready connector in being built for your specific case, including when one of the systems appears on nobody's integration list.
How long does an API integration take?
One week of workshop and 2 to 4 weeks of rollout, pilot on real data included. The date slips for two reasons above all: missing documentation on the on-premise side, or waiting for access from the vendor. We check both in the workshop, before we give you a date.
What if our system has no API documentation?
We check what it actually exposes: batch export, file import, database views, browser traffic after login. That is usually enough to build a data exchange, though more often on a schedule than in real time. If there is no way in at all, we say so and we do not take on an integration nobody could keep alive.
How do you handle rate limits and pagination?
The integration knows the vendor cap and manages its own window: it queues calls, spreads them over time and backs off when it gets a rate limit response. It reads data page by page with a last-modified marker, so after an interruption it resumes from the last confirmed record rather than the start of the catalogue. Limits live in the configuration, not in a code comment.
What happens when a token expires or the vendor changes the API?
An OAuth token refreshes automatically, and a static key has its expiry date recorded with an alert 7 days ahead. The API version is kept in the configuration and monitoring checks the shape of responses. When a vendor retires a field or changes a format, you see it on the day of the change, so the fix lands before the process stops.
How much do API integration services cost?
The only fixed price is the process workshop: EUR 3,500 net per week, and for a single integration one week is usually enough. The integration itself is quoted after the workshop, because the cost depends on things nobody knows before it: how many systems are involved, whether their APIs are documented, whether the vendor offers a test environment, and whether data moves in one direction or both. Platform, hosting and language model fees you pay directly to the provider, with no margin from us.
Who owns the integration code?
You do. The code, the configuration, the field mapping sheet and the access description stay with you, along with repository access. The integration can run on your infrastructure or in your own automation platform account. Dependence on us ends on handover day, and that is deliberate.
How does a custom integration differ from a ready connector?
A ready connector is faster and cheaper everywhere it exists and covers your case, and we will tell you so. A custom integration is for the places where no connector exists, where it ignores rate limits or pagination, where fields have to be converted between different data models, or where two sources of truth have to be reconciled.
Let us find out whether your systems can be connected
The free consultation takes 30 minutes. Name the systems that should talk to each other and say what someone retypes by hand today. We will tell you whether a ready connector exists, whether an integration has to be written, and where we would start. You do not have to share systems or documentation at this stage.
We run at most two rollouts at a time, so that someone is genuinely sitting on each of them.
Book a free consultationPS. If the same VAT number gets typed into three systems in your company today, that is exactly this problem. An integration takes those three entries and leaves one, and the workshop document stays with you even if someone else does the rollout.