API integration
Most businesses already own the tools they need. The trouble is that the payment provider, the accounts package, the email platform and the CRM each hold a slightly different version of the truth, and somebody in the office keeps them agreed by hand. We connect them properly so that stops being anyone's job.
What this covers
Sometimes this is a single link between two systems that saves a person an hour a day, and sometimes it is the whole spine holding an admin panel, a customer app and your accounts together. The engineering underneath is the same either way.
Stripe checkout, subscriptions and saved cards wired into your own system, so a payment, a refund or a failed renewal updates the customer record on its own. Your team answers a billing question from the screen they already work in, without logging into a separate dashboard to find the truth.
GoCardless mandates and recurring collections handled from setup through to the parts nobody enjoys. When a collection fails, the account is updated, the retry happens on the terms you set, and somebody is told, rather than a customer quietly sitting there marked as paid.
Xero connected in both directions, so invoices and payments raised in your system land in your accounts, and anything your bookkeeper reconciles comes back the other way. Month end stops being an export, a spreadsheet and an afternoon of comparing two lists.
Receipts, reminders, approvals and password resets sent through Postmark on a properly authenticated sending domain, so they arrive rather than landing in spam. Bounces and complaints come back to you and attach to the customer they belong to.
Customer records, leads and published content kept in step between your app and the platforms your sales, marketing and editorial people live in. Nobody exports a spreadsheet on a Friday afternoon to make two systems agree with each other.
Address lookup and validation on your forms, operational reports written straight into a spreadsheet for the people who genuinely prefer one, and documents filed automatically into shared storage using credentials the business owns rather than one employee.
How we approach it
On the day an integration goes live the credentials are fresh, the test account holds a handful of records and every message arrives once and in the right order. Two years later the credentials have rotated, a customer has paid the same invoice twice, the payment provider has sent the same notification four times because your server was mid-deploy, and somebody has renamed a contact in the accounts package. We build for the second version of that story, because that is the one your business has to live in.
Anything that moves money or creates a record is written so it can safely be told the same thing twice, since providers promise to deliver a message at least once rather than exactly once. Long jobs take a lock, so a scheduled sync and somebody pressing the re-sync button cannot both edit the same record in the same second. And every message that arrives is written down as it came in, so when something needs correcting later there is a real record to correct it from.
The unglamorous parts
Access tokens are where most integrations quietly die. Providers expire and rotate them constantly, and if two processes go to renew at the same moment, one of them is left holding a key that is already dead and the connection drops. We keep credentials in one place, renew them behind a lock and let the process that gets there first publish the new pair for everything else to use. The connection repairs itself instead of waiting for somebody to notice that invoices stopped appearing.
Scheduled checks compare the two systems and report anything that has drifted apart, so a payment that exists with your provider but never reached your accounts is caught by a report overnight rather than by your accountant months later. Whatever the check cannot settle on its own is put in front of a person, with enough context attached to fix it in a minute rather than investigate it for an afternoon.
The dangerous integration is the one that fails silently and leaves everybody trusting numbers that stopped being true weeks ago. Ours are loud. If a connection stops responding or a scheduled job does not run, an alert reaches a real person with the detail needed to act on it, and the affected records stay visibly flagged until somebody has dealt with them.
Start a project
Name the systems you use and what should happen when a record changes in one of them. We will come back with questions, a shape for the work and a straight answer on whether the platforms involved can actually do what you have in mind.