API and System Integrations

What are API and system integrations?

Integration means independent pieces of software sharing particular data automatically. An organisation usually runs several systems: an accounting program, an ERP, a CRM, an e-commerce site, a courier's panel, a bank interface. Each may work well on its own; the problem is usually between them.

The gap in between gets filled by people. The same order is entered into one system and copied by hand into another, the stock list is exported and re-uploaded once a week, and at month end somebody investigates why two reports do not agree. This is an invisible cost: it is in nobody's job description, it takes time out of everybody's day, and it is where most errors originate.

An API (application programming interface) is the door a system opens to the outside: it defines what data can be read, what can be written and how. The integration job is to connect those doors correctly, find a suitable route for systems that have no door, and build a structure where the flow does not degrade over time.

The difficulty in this work is usually not technical but about limits: what the other system permits, what its supplier commits to, and what form the data is actually held in. That is why, before promising an integration, we review the other side's documentation and a sample of its real data; a connection that looks possible on paper can turn out to be limited in practice, and it is better to know that from the start.

What we do

Integration projects generally start with a single connection and grow. That is why, even on the first build, we set the flows up as an extensible structure rather than as individually written scripts. The second and third connections then reuse the logging, error handling and monitoring the first one established.

• Data flow between systems — We build the flow of orders, stock, account balances, invoices and customer data between ERP, CRM, accounting, e-commerce and internal applications. Which data flows in which direction becomes visible on a single diagram.
• API development — When your own system needs to be opened up, we write the API: authentication, authorisation, versioning, rate limiting and documentation included. An undocumented API produces the same result as no API at all.
• Third-party service connections — Connections to external services such as payment, shipping, e-invoicing, SMS and mapping are set up. The failure modes and retry behaviour of those services are part of the job.
• Automated synchronisation — Scheduled tasks keep data in step at regular intervals. Only changed records are transferred; moving the whole data set every time is both slow and hard on the other system.
• Webhook setup — Notification arrives the moment an event happens. We verify that the notification genuinely came from the other system and prevent the same notification being processed twice.
• Logging and monitoring — When each transfer ran, how many records it moved and which ones failed are all recorded. A persistent failure raises a notification; the flow does not stop quietly.
• Data transformation — Two systems hold the same information in different forms: date format, currency, product code, tax rate. Transformation rules are defined in one place and documented.
• Security — Authentication keys are not held inside application code, access is limited to the data actually needed, and connections are made over encrypted channels. An integration is a new door opened between two systems; who that door is open to has to be defined.
• Documentation and handover — The flow diagram, field mappings and transformation rules are left in writing. Maintaining integrations becomes the hardest job of all when it depends on the memory of whoever wrote them.

How we work

1. System inventory — Which systems exist, what data each holds, and what is currently carried between them by hand. Without that map there is no way to know which integration will genuinely produce value.
2. Deciding ownership — For each data field we establish which system owns it. Which one wins in a conflict is put in writing; if that decision is left until later, it gets made through data loss.
3. Choosing the connection method — We decide whether the other system's API, database access or file transfer is the appropriate route. If the other side's supplier needs to be spoken to, we handle that conversation.
4. Building in a test environment — The integration is first built somewhere other than production and tested against a copy of real data. Learning that a transfer runs in the wrong direction is expensive to discover in production.
5. Phased go-live — The flow is opened first in one direction with a limited data set; once accuracy is confirmed, the scope is widened.
6. Monitoring and maintenance — After launch the logs are reviewed regularly. Version changes in the other system, expiring keys and deprecated endpoints are all tracked.

What you gain

• The end of manual data entry — Transfers that run on copy and paste disappear; the time saved is directly measurable.
• Consistent data — The same information looks the same in every system. Reports that do not agree get fixed at source.
• Fewer errors — Manual entry is the largest source of error. In an automated flow, the rules are defined once and run the same way every time.
• Speed — Order, stock and payment information reaches the relevant system within minutes; nobody waits for end of day.
• Visibility — Whether the flows are running can be monitored. A problem is discovered through a notification, not through a customer complaint.
• Protecting existing investment — Connecting systems instead of replacing them is usually both faster and less risky.

A well-built integration goes unnoticed; a badly built one reminds you of itself every month. Our aim is to leave behind flows that nobody has to think about once they are running, and that announce themselves when they break.