The most common style: resources over HTTP with JSON. We handle pagination, filtering, partial updates and bulk endpoints where the provider has them.
API integration services
API integration services for connections that have to hold
Two systems, a written contract between them, and code that handles the day the other side misbehaves. We build custom API integrations and connectors for third-party and in-house APIs, with authentication, rate limits, idempotent retries and monitoring included.
- System AOrder created in your appEvent published to the connector
eventOrder event receivedorder.created
- ConnectorMap and validateYour Order -> their Shipment schema
eventQueued with an idempotency key
- Rate-aware queueSend within the allowed rateOAuth token cached and refreshed
- HTTP 429 or 5xxBackoffRetry with exponential delaySame key, so no duplicate shipment
eventRequest sentPOST
- HTTP 429 or 5xx
- System B · APIPOST /v1/shipments201 Created, shipment ID returned
eventStatus changes laterwebhook
- Webhook endpointPOST /hooks/shipmentSignature checked before processing
- Bad signatureRejected401, logged and alerted
eventTracking written backshipment.updated
- Bad signature
- System AOrder shows tracking numberLinked by external ID
- Event-driven
- Failure path
What API integration is
API integration connects software systems through their application programming interfaces, so one system can read data from another or trigger actions in it without people copying information between screens. A third-party API integration connects to an API run by another company, such as a payment, shipping, accounting or CRM provider. A custom API integration is code written for your data model and process, rather than a pre-built connector.
Native connector, iPaaS or custom code?
Custom code is not always the answer. We recommend the cheapest option that will still work in a year.
| Option | Fits when | Breaks when |
|---|---|---|
| Native connector | Both vendors support the exact objects and direction you need, and the defaults match your process. | You need custom fields, different matching rules, or visibility into failed records. |
| No-code automation (Zapier, Make) | Low volume, simple trigger-action steps, and a missed run is easy to notice. | Retries create duplicates, logic spreads across many flows, or volume hits task limits. |
| iPaaS (Workato, MuleSoft, Boomi and similar) | You already own a platform and a team to run it, and integrate many systems. | The mapping and error design are weak; the platform does not fix that by itself. |
| Custom integration service | Edge cases, high volume, two-way sync, audit trails, legacy protocols, or an API that connectors don’t support. | Nobody owns it after launch. We plan the handover or the support from day one. |
The five stages of an API integration
Each stage ends with an artifact you can review before money is spent on the next one.
Discover and agree the contract
Read both APIs’ documentation, test them in sandboxes, confirm the objects, authentication method, rate limits and webhooks actually available on your plan.
DeliverableInterface contract: endpoints, fields, auth, limits, error codes
Design mapping and flows
Decide what triggers each flow, how records are matched, how fields and codes translate, and which system owns each field.
DeliverableMapping spec and flow diagrams
Build the connector
Implement authentication, pagination, batching, idempotency keys, retries with backoff, logging and configuration for each environment.
DeliverableConnector code in your repository, with configuration per environment
Test against sandboxes and real samples
Contract tests on the API shapes, end-to-end tests with copies of real records, and failure tests: expired tokens, 429s, timeouts, malformed payloads.
DeliverableTest report covering edge cases and failure modes
Deploy, monitor and maintain
Release behind a switch, backfill if needed, watch the first runs, then keep it current as the APIs evolve.
DeliverableRunbook, dashboards and alert rules
The engineering checklist
What separates an integration that survives production from one that works in a demo.
| Concern | What we do | Why it matters |
|---|---|---|
| Authentication | OAuth 2.0 with token refresh, or API keys stored in a secret manager; the narrowest scopes that work. | Expired tokens are the most common cause of silent stops. |
| Pagination | Cursor or offset handling for every list call, with a watermark for incremental reads. | Without it, only the first page of records ever syncs. |
| Rate limits | A queue that respects the provider’s limits, reads rate headers where offered, and backs off on HTTP 429. | Bulk changes otherwise lock the account out for everyone. |
| Idempotency | An idempotency key or upsert by external ID on every write. | A retried request must not create a second order or invoice. |
| Webhooks | Signature verification, fast acknowledgement, processing from a queue, handling of duplicate and out-of-order events. | Providers retry deliveries and don’t guarantee order. |
| Timeouts and retries | Explicit timeouts, exponential backoff with jitter, a retry ceiling, then a dead-letter queue. | Hanging calls and endless retries hide real failures. |
| Versioning | Pinned API versions, contract tests, a calendar of deprecations. | Provider changes break integrations on someone else’s schedule. |
| Schema drift | Validation of incoming payloads; unknown fields logged, missing required fields rejected to review. | A renamed field should fail loudly, not write empty values. |
| Secrets and data | No credentials in code, personal data kept out of logs, payloads stored only as long as needed. | Integrations touch customer data across systems. |
API styles we work with
Not every system offers a modern REST API. We connect to what exists.
- REST
REST APIs
- GraphQL
GraphQL
A single endpoint where the client asks for exactly the fields it needs. Useful for nested reads; we watch query cost limits.
- SOAP
SOAP and XML services
Still common in ERP, logistics and finance systems. We generate clients from WSDL and translate to modern formats at the edge.
- Events
Webhooks and event streams
Push notifications when something changes, so the integration reacts in seconds instead of polling.
- Files
SFTP and file batches
CSV or XML drops on a schedule, where a partner offers nothing else. We validate files, reconcile counts and archive what was processed.
- Database
Database access and change capture
When a legacy system has no API, reading from a replica or change log, with the owner’s agreement and never writing behind the application’s back.
Typical third-party API integrations
Examples of the APIs businesses most often connect. Each has its own rules for authentication, limits and testing.
Payments
Payment intents, refunds and payout reports from a payment provider, reconciled with orders and invoices.
Accounting and invoicing
Customers, invoices, credit notes and payment status, kept consistent with the CRM or order system.
Shipping and logistics
Rate quotes, label creation, tracking events and proof of delivery from carriers or fulfilment partners.
Tax and address validation
Tax calculation and address checks at quote or checkout, before an order reaches the ERP.
E-signature
Sending contracts from the CRM and writing signature status and signed documents back to the record.
Maps and geolocation
Geocoding addresses, territory assignment, travel time for field visits.
Identity and SSO
User provisioning and single sign-on for portals and internal tools.
Messaging
Email, SMS and WhatsApp delivery and inbound messages linked to customer records. See WhatsApp CRM integration.
CRM platforms
Salesforce, HubSpot, Dynamics 365, Zoho CRM, Pipedrive and custom CRMs. For CRM-centred projects, see CRM integration services.
API development for integration
Sometimes the missing piece is an API on your side.
If partners, a mobile app or another internal system need to reach your application, and it has no suitable API, we build one. The design starts from the integrations it has to serve, not from a generic resource list.
- Resources and contracts described in an OpenAPI document that clients can generate code from.
- Authentication with OAuth 2.0 client credentials or scoped API keys, per client, revocable.
- Pagination, filtering and rate limits that protect your application from heavy clients.
- Webhooks with signed payloads and retries, so clients don’t need to poll.
- Versioning and deprecation policy written down before the first external client connects.
Monitoring in operation
An integration that runs unattended needs to report on itself.
shipments-connector · last hourillustrative
- 15:01:09okapp -> carrier · shipmentOrder 55821 -> shipment created, 201 in 340 ms
- 15:03:44retryapp -> carrier · shipmentHTTP 429, backing off 8s (attempt 2 of 6)
- 15:03:53okapp -> carrier · shipmentAccepted on attempt 2; idempotency key matched, no duplicate
- 15:12:30failedcarrier -> app · webhookSignature mismatch, request rejected with 401, security alert raised
- 15:20:02failedapp -> carrier · shipmentPostcode fails carrier validation, moved to review queue
- 15:30:00queuedtoken refreshOAuth token expires in 10 min, refresh scheduled
- Health you can see. Success rate, latency, queue depth and retry counts per flow on one dashboard.
- Alerts with context. Each alert links to the runbook entry that says what it means and what to do.
- Replay after a fix. Records held in the review queue can be resent once the cause is corrected.
- Correlation IDs. One identifier follows a record across both systems, so a support question takes minutes.
What you receive
Everything needed to run, change or hand over the integration.
Contract
Interface contract
Endpoints, fields, authentication, limits, error codes and retry behavior for each flow, agreed before the build.
Data
Mapping spec
Field-by-field mapping, match keys, code translations and validation rules.
Code
Connector in your repository
Source code, infrastructure definitions and configuration per environment, in your accounts.
Quality
Automated tests
Contract tests against API shapes and end-to-end tests with realistic data, run on every change.
Operations
Runbook and alerts
Dashboards, alert rules, and what to do for each alert, including how to replay records.
Change
Maintenance plan
Pinned versions, known deprecation dates and who checks provider release notes.
What drives the cost
We estimate after seeing the APIs and sample data. These are the factors that move the number.
Number of flows
Each trigger-to-target path is designed, built and tested separately. Two-way sync counts as at least two.
API quality
Clear documentation, sandboxes, webhooks and bulk endpoints reduce work. Legacy SOAP, file drops or missing sandboxes add it.
Data complexity
Custom fields, code translations, deduplication and validation rules take more time than the API calls themselves.
Volume and timing
High volume or near-real-time needs require queues, batching and careful limit management.
Backfill
Linking or loading existing records before live sync starts is often a project step of its own.
Operations
The level of monitoring, alerting and support you need after launch.
Which integration page fits?
API integration is the connector level. These pages cover the other levels.
- Ifthe CRM is the centre of the project and the question is which customer data lives whereCRM integration Field ownership, sync modes and CRM platform APIs./crm/crm-integration/
- Ifa business process spans several applications and needs orchestrating end to endSystems integration Ownership map, integration patterns and cross-system workflows./integrations/systems-integration/
- Ifthe API in question is the WhatsApp Business PlatformWhatsApp & CRM Templates, the customer service window, routing and CRM logging./integrations/whatsapp-crm-integration/
- Ifthe connector is one part of a wider CRM and integration project.CRM & integrations Overview of every CRM and integration service./crm/
Questions about API integration
What are the 5 stages of API integration?
A practical breakdown is: (1) discover the APIs and agree an interface contract, (2) design the data mapping and flows, (3) build the connector with authentication, limits and error handling, (4) test against sandboxes and real sample data, and (5) deploy, monitor and maintain it as the APIs change. Each stage should end with something you can review: a contract, a mapping spec, code, a test report and a runbook.
What is a third-party API integration?
It is a connection between your software and an API run by another company: a payment provider, a shipping carrier, an accounting system or a CRM. You don’t control the third party’s API, its limits or its release schedule, so the integration has to handle errors, rate limits and version changes on its side.
How much do API integrations cost?
Cost depends on the number of systems and flows, the quality of the APIs, how much mapping and validation the data needs, whether sync is one-way or two-way, the volume, and the monitoring you need. A single one-way flow between two well-documented REST APIs is a small project; a two-way sync with a legacy SOAP system is not. We estimate after reviewing the API documentation and sample data, and we don’t publish a price list because the range is too wide to be useful.
Is ETL the same as API integration?
No, although they overlap. ETL (extract, transform, load) moves data in batches, usually into a warehouse for reporting. API integration usually connects operational systems record by record, often in near real time, and may trigger actions such as creating an order. Many projects use both: APIs for the live process, scheduled extracts for reporting.
How do you handle API changes and versioning?
We pin the API version the connector uses, subscribe to the provider’s change notices, and run contract tests that fail when a response no longer matches the agreed shape. When a version is deprecated, the upgrade is planned and tested in a sandbox before the cut-off date.
Can you build the API on our side too?
Yes. When partners or other systems need to reach your application, we design and build the API: resources, authentication, versioning, pagination, rate limits, webhooks and documentation. That is API development in service of integration, not a separate product.
Do you work with integration platforms such as Workato, MuleSoft or Zapier?
Yes. If you already run an iPaaS or automation tool, we can build within it. Where it can’t handle the logic, volume or error handling, we write a small custom service and connect the two. If the real need is automating a multi-step business workflow rather than one connector, see business process automation.
Next step
Send us the two APIs
Tell us which systems need to talk, what should happen between them, and where the current setup fails. Links to API documentation help a lot.
Scope an API integrationUseful to have ready
- The systems and their API documentation, if you have it
- What should trigger each flow, and what it should create or update
- Volumes and how quickly changes must arrive
- Current scripts, connectors or iPaaS flows, and what goes wrong with them
Not everything is needed. A rough answer is enough to start.