Make your systems talk to each other — and keep talking
API development and integration covers two connected jobs: building APIs so other systems can use your data and functions, and wiring existing systems — ERP, CRM, ecommerce, billing, warehouse — into each other so information moves without a person re-typing it. It removes swivel-chair integration: the employee whose actual job is copying data from one screen into another.
Willowark builds contract-first. An API begins as an OpenAPI specification both sides can code against, with explicit versioning so future changes never break existing consumers. Integrations are built for the real world: retries with idempotency keys so a network blip cannot create a duplicate order, and monitoring that notices silence — because the most dangerous integration failure is the quiet one.
Software EngineeringHow the work gets done
The same way every time: scope, build, hand over.
The details are where integrations live or die: OAuth2 and API-key authentication done properly, pagination that doesn't drop records between pages, rate-limit handling that backs off instead of hammering, webhook receivers that verify signatures and tolerate replays, and adapters that isolate each third-party quirk so one vendor's oddities never spread through your codebase.
Every integration ships with an operational layer: sync-health dashboards, dead-letter queues for records that failed to transfer, and reconciliation reports that compare both ends on a schedule and surface drift. That last one converts 'we think the systems match' into a checked fact.
Scoping an integration begins with a data map: which system owns each record, which direction each field flows, and what happens when both sides change the same thing. That last question is where most projects hide their real complexity, so we settle conflict rules before writing code. We also decide, per dataset, how fresh it needs to be — because real-time sync costs more to build and operate than a nightly batch, and much of the data in a typical business does not need to move within seconds. Choosing batch where batch is fine is how integrations stay affordable to run.
Integrations break in ways nobody sees: a vendor renames a field, a token expires over a holiday, a record with a stray character stalls the queue and everything behind it waits. We design against this with contract tests that fail loudly when a vendor's response changes shape, credential expiry monitored, and per-record failure isolation so one bad row goes to a dead-letter queue instead of stopping the line. Handover includes a runbook for each integration — where to look when the sync dashboard turns red, how to replay a failed batch, and whom to contact at the vendor. Your team should be able to run it without reading code.
Scope it in writing
What we agree before work starts
- OpenAPI-specified, versioned APIs with authentication and rate limiting
- Integration services with retries, idempotency keys, and dead-letter handling
Build with checkpoints
Working results, not slide decks
- Webhook infrastructure with signature verification and replay tolerance
- Sync monitoring and scheduled reconciliation reports
Hand over something you own
Documentation, source, and training
- Developer documentation and sandbox access for API consumers
- Per-integration runbook covering failure replay, credential rotation, and vendor escalation
Sound familiar?
Where api development & integration earns its keep.
Ecommerce orders re-typed into the ERP every morning while inventory counts drift apart
A CRM and a billing system that disagree about which customers are active
A partner who needs API access to your inventory, but your system has no API
Six SaaS tools connected by CSV exports someone runs by hand each Friday
Ask about API Development & Integration
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
AI operating software for training operations
Components:
- Schedulers (training ops): The people running the training operation.
- Operating software (AI assistance): The operating software, with AI assistance built in.
- Cloud services (distributed): Distributed cloud services behind the application.
- Training game (learning): The training game the software connects to.
Connections:
- Schedulers to Operating software
- Operating software to Cloud services
- Operating software to Training game
A global automotive manufacturer's training operation · Automotive
AI operating software for training operations
AI operating software for the manufacturer's training schedulers — removing manual scheduling labor and logistics tracking, saving hundreds of hours per year — plus a training video game built to help trainers perform better. Used across the manufacturer's training organization.
Read the case study →Common questions
Asked before every api development & integration project.
What if the vendor's API is bad or barely documented?
Common, and workable. We probe the API's actual behavior, wrap it behind an adapter that isolates its quirks, and pin the discovered behavior in tests so a silent vendor change gets caught. Where no API exists at all, we weigh database-level access, file exchange, or managed automation of their interface — in that order.
Should the integration be real-time or batch?
It depends on the data. Order flow and inventory usually justify event-driven sync through webhooks or queues; reference data like product catalogs is often better on a scheduled batch that is simpler and cheaper to run. Most real architectures mix both, matched to how fresh each dataset genuinely needs to be.
How do you handle API changes over time?
For APIs we build: versioning from day one, so consumers migrate on their schedule instead of being broken on ours. For APIs we consume: contract tests and monitoring that detect a vendor change quickly, plus adapters that keep the blast radius to one module. Integration is an operational commitment, and we build like it.
Which systems have you integrated before?
The usual suspects across ERP, CRM, ecommerce, accounting, shipping, and payment platforms, plus plenty of in-house and industrial systems that had no proper API at all. We avoid listing products here because the specific one matters less than you would think: the hard parts — authentication, pagination, rate limits, conflict rules, silent failures — recur everywhere. If your system is unusual, the early part of the engagement is spent learning exactly how it behaves.
What happens when the integration fails at 2 a.m.?
Nothing dramatic, if the design is right. Failed records land in a dead-letter queue rather than being lost, the sync keeps processing everything else, and an alert goes to whoever you have designated — not necessarily anyone at 2 a.m., because most integration failures can wait until morning. The runbook explains how to inspect and replay what failed. For flows that genuinely cannot wait, we agree on escalation and can include on-call support in a maintenance arrangement.
Where this sits
API Development & Integration, inside a software engineering system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Users reach a web app that talks to an API over a database, with background workers for the slow work and integrations to the systems already in use.
Components:
- Users: Staff, customers, or both.
- Web app: The interface: fast, accessible, works on a phone.
- API: Typed, versioned, authenticated.
- Database: Postgres, usually. Backed up, migrated, monitored.
- Workers (jobs, queues): Reports, syncs, emails — anything that should not block a click.
- Integrations (existing tools): Accounting, CRM, email, payments.
Connections:
- Users to Web app over REST
- Web app to API over REST
- API to Database over SQL
- API to Workers over events
- Workers to Integrations over webhook, both directions
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.