On this page
What third-party integration really involves
Calling an external API once, in a demo, is easy. Keeping that call working every day for years is the real job. Vendors have rate limits, occasional outages, undocumented behaviour, fields that are sometimes missing, and version changes announced with little notice. An integration that ignores all this works fine until the day it silently stops.
We start by reading the documentation carefully, then test what the API actually does against a sandbox or test account — because the two are not always the same. From there we build a dedicated client layer inside your application that handles authentication, retries, timeouts and error mapping in one place.
Where this usually comes up
- An e-commerce store connecting a courier or shipping aggregator for rates, labels and tracking updates.
- A clinic sending appointment reminders through an SMS or WhatsApp provider.
- A real estate portal pulling map, geocoding or listing data from an outside source.
- A SaaS startup integrating accounting, e-signature or email-sending services into its product.
- A manufacturer pushing orders to a logistics partner’s platform.
Signs an existing integration needs attention: it fails without anyone noticing, staff re-run jobs manually, the vendor’s error messages appear directly to your customers, or nobody on the team knows where the API credentials are stored.
What we deliver
- A wrapped client layer, so the rest of your code never calls the vendor directly.
- Timeouts on every call and retries with backoff for errors that are safe to retry.
- Respect for the vendor’s rate limits, with queuing where volumes are high.
- Clear mapping of vendor errors into messages your team and users can act on.
- Secure storage of credentials and tokens, including OAuth 2.0 refresh handling where the vendor uses it.
- Logging of requests and responses (with sensitive data masked) for troubleshooting.
- Alerts when the integration starts failing, rather than discovery days later.
Our process
- Understand the goal. What should happen in your business when the integration runs, and what should happen when it can’t?
- Probe the API. We test real requests in a sandbox, noting where behaviour differs from the documentation.
- Design the wrapper. One module owns the vendor relationship; the rest of your system talks to it through a simple interface.
- Build the failure paths. Timeouts, retries, partial data, expired tokens and vendor downtime are all handled deliberately.
- Test and monitor. Automated tests use recorded or mocked responses, and live monitoring watches error rates after launch.
When the documentation is poor or missing
Incomplete documentation is a normal working condition, not a blocker. We work from sandbox testing, sample payloads, SDK source code where it’s available, and careful logging of real responses. Where a vendor has a support channel, we raise precise questions with example requests attached, which tends to get useful answers faster.
We also write down what we learn. Undocumented behaviour, odd field formats and known vendor limitations are recorded in the integration’s own notes, so the next developer who works on it — ours or yours — doesn’t have to rediscover them the hard way.
What affects timeline and cost
- The quality of the vendor’s documentation and whether a sandbox is available.
- How many endpoints or operations you need, and whether data flows one way or both.
- Volume — high-volume integrations need queuing and more careful rate-limit handling.
- Authentication complexity, such as OAuth 2.0 flows per customer account.
- How your existing code is structured and whether an older integration must be replaced in place.
Common mistakes
- No timeout, so one slow vendor response ties up your whole application.
- Retrying everything, including requests that aren’t safe to repeat — such as creating a shipment twice.
- Hard-coding API keys in the source code or a committed config file.
- Scattering vendor calls throughout the codebase, which makes any change expensive.
- Assuming a successful HTTP status means the operation actually succeeded, without checking the response body.
Frequently asked questions
Can you integrate an API we’ve never heard of?
Usually, yes. If the service offers an HTTP API — REST, SOAP or something older — we can build a client for it. We’ll test it in a sandbox first and tell you about any limitations before committing to scope.
What happens when the vendor’s service is down?
The integration is built to expect it. Depending on the case, requests are queued and retried later, your users see a clear message, and your team gets an alert if the problem persists.
Can you fix an integration someone else built?
Yes. We review the existing code, identify where it fails, and either repair it or move it behind a proper wrapper if the problems are structural.
How are API credentials stored?
In environment variables or a secrets manager on the server, never in the source code repository. Access to them is limited to the systems that need them.
What if the vendor changes or retires their API version?
Because all vendor calls go through one wrapper, the change is contained to that layer. If you’re on a maintenance arrangement with us, we watch for deprecation notices and plan the update before the old version stops working.
Talk to us about third-party api integration
Connect any external service — including the ones with confusing or incomplete documentation.