API design
Versioned REST or GraphQL interfaces with a published schema, consistent errors, pagination that works, and documentation generated from the source.
System integration & API engineering
Most companies do not need another system. They need the ones they already run to agree with each other — reliably, in the right order, and in a way that lets you answer "where did that record go?" in minutes rather than days.
01 — Position
Integration is a data-consistency problem wearing a plumbing costume
Connecting two systems is easy for a week. It gets hard the first time a request times out after the remote side already committed, or a webhook arrives twice, or a nightly job runs while yesterday's is still finishing.
So we design for those cases first: idempotent operations, explicit retry and backoff, dead-letter handling, and a reconciliation routine that compares both sides and reports the difference rather than hoping there is none.
We are comfortable working against legacy systems with incomplete documentation, undocumented quirks and a support contact who left in 2019. That is normal.
Non-negotiables in every integration
- Every write operation is idempotent or explicitly guarded
- Retries use backoff and have a terminal state
- Failed messages land somewhere a human can inspect them
- A correlation id follows a transaction across every system
- A scheduled reconciliation reports drift before a customer does
- Credentials are scoped per environment and rotatable
02 — What we build
Scope of the practice
ERP & CRM connectors
Two-way synchronisation of customers, orders, stock and invoices, with field mapping documented and owned by you rather than buried in a config screen.
Payments & billing
Payment provider integration with webhook verification, idempotent capture, refund flows and a ledger that reconciles against the provider's own report.
Event pipelines
Queues and streams with ordering guarantees you actually need, consumer groups, replay, and a dead-letter queue nobody has to guess about.
Legacy bridges
SOAP, flat files, SFTP drops, fixed-width exports and databases queried directly — wrapped behind a modern interface so nothing else has to know.
Observability
Structured logs, traces and dashboards that make an integration debuggable by someone who did not build it.
03 — Delivered
What ends up in your hands
- An integration map naming every connected system and direction of flow
- Published API documentation generated from the schema
- Field mapping in a document your operations team can read
- Error handling rules stating what retries, what alerts, what stops
- A reconciliation job and the report it produces
- Traceable audit logging for every cross-system transaction
Typical stack
- Interfaces
- REST with OpenAPI, GraphQL where a client genuinely benefits
- Messaging
- Redis streams, RabbitMQ, Kafka or a cloud-native queue
- Scheduling
- Idempotent jobs with locking and a visible run history
- Data
- PostgreSQL as the system of record; staging tables for imports
- Contracts
- Schema validation on both sides of every boundary
- Secrets
- Managed secret store, never in the repository
- OpenAPI
- GraphQL
- Kafka
- RabbitMQ
- PostgreSQL
- Go
04 — Questions
About integration work
The vendor's API documentation is wrong. Is that a problem?
It is the normal case. We verify behaviour against a sandbox or a scoped test account before designing around it, and we record the actual behaviour in our own documentation. Where a vendor's API is genuinely unusable, we say so early rather than absorbing the cost silently.
Can you integrate a system we cannot give you access to?
Not blindly. We can work against a copy, a sandbox, an export or a screen-shared session with someone who has access — but we will not guess at a contract. If access is genuinely impossible, we will scope the work as discovery until it is not.
Who owns the integration once it is running?
You do. The code, the credentials and the infrastructure are yours. We can stay on under a maintenance agreement — integrations break when a third party changes something, which is not an event you can schedule — but that is your choice, not a lock-in.
List the systems that disagree with each other
Names and directions are enough to start. We will come back with the failure modes we would design against.
HALDIR LTD · HE 459882 · Nicosia, Cyprus