API development and integration for the systems you run and the partners you serve.

Customers and partners integrate with you directly instead of emailing spreadsheets. We design, build, and document the APIs, webhooks, and vendor connections that make it work, with keys, scopes, rate limits, and a sandbox to test against.

Scope an API project How the work runs

Who hires us for this

Technology and operations leads who need an interface rather than a screen: a customer who wants to send orders by API, a partner who needs your data, an internal system that has to expose what it holds, or a vendor API that the business has to build on. Often the current answer is a file exchange, an email, or a person.

Why now

A large customer or partner has asked for an API, and the current answer is a spreadsheet by email.
Two of your own systems need to exchange records and the vendor connector does not exist.
A third-party API is at the center of a new product and nobody has tested its limits.

A decision, not a pitch

Consume, expose, or both?

The word API covers three different projects. This is how we tell them apart on the first call.

Consideration	Consume a vendor’s API	Expose your own API	Connect two systems
The need	Your software must use a service someone else runs	Others must build on what your system holds	Records must flow between systems you run
The risk	Their limits, changes, and outages	Your compatibility promises and security	Ownership of each record, and what fails silently
What we inspect first	Authentication, rate limits, data shape, licensing, support	Who the consumers are and what they need	The record map and who owns each field
What you get	A resilient client with retries and monitoring	A versioned, documented API with keys and a sandbox	A monitored flow with an exception queue

Most projects mix the three. The scope names which parts are which.

What this covers

What API development and integration covers.

APIs for your own systems

Interfaces that expose records and actions from your application, so other systems and teams can build on them.

Customer and partner APIs

Ordering, status, documents, and data feeds for the customers and partners who want to integrate with you, with keys, limits, and documentation.

Webhooks and events

Notifications when something changes, so the other side does not have to poll.

Third-party API integration

Building on the APIs your vendors expose: authentication, rate limits, data shape, and failure handling inspected before we agree on the scope.

Authentication and access

Keys, tokens, scopes, and audit, so each consumer sees only what it should.

Documentation and versioning

A reference your consumers can use without a call, and a way to change the API without breaking them.

When companies call us

If this sounds like your business, here is where we start.

A customer wants to place orders from their own system

An ordering API with keys per customer, validation, order status, and a webhook on shipment.

A partner needs your inventory or pricing feed

A read API with scopes per partner, rate limits, and documentation, replacing the nightly file.

Your product must connect to a vendor with a difficult API

A proof of concept against the real API first, then an integration with retries, exceptions, and monitoring.

Internal systems exchange records by export

An internal API on the system of record, so the others read live data instead of yesterday’s file.

How the work runs

Scoped in writing, built in releases, handed over.

01
Name the consumers
Who will call the API, what they need to do, and what they must never see.
02
Design the contract
Resources, actions, errors, and versioning, written down and reviewed with a consumer before any code is written.
03
Build with the controls
Authentication, scopes, rate limits, validation, and audit from the first release.
04
Document and test with a consumer
A reference and a sandbox; the first consumer integrates before launch.
05
Monitor and version
Usage, errors, and latency visible; changes released without breaking existing consumers.

Deliverables

What you receive.

ScopeAgreed

First release · version 1.2Scope and acceptance

Includes: The core workflow, roles and permissions, and the first integration
Left for later: Reporting and the second integration
Acceptance: Criteria agreed with your team
Price: Fixed before the build begins
Start date: Agreed in writing

Approved by operations Approved by finance

RunbookHanded over

Operations · version 1.0Running the system

01Deploy a releasePipeline
02Roll back a releaseTested
03Restore from backupTested
04Alerts and who respondsCurrent
05Access and secretsBy role

Written scope
What the first release includes, what it leaves for later, the integration decisions, the acceptance criteria, and the price, agreed before development begins.
Release notes
What changed in each release, what was tested, what the security review covered, and how to roll it back.
Documentation and runbooks
How the system is built, how to run it day to day, and what to do when something fails.
Training and handover
Sessions with the people who will use and run the system, and a handover checklist your team signs off on.

Every release ships with tests, a security review, and documentation, so your team can run what we build.

CRM
ERP / finance
Field application
Validate and map
validDestination
failedException queueowner resolves, then retry

The parts of an integration that decide whether it can be trusted.

Your first release

What the first release could include.

The scope is written and agreed before development starts. This is the shape it usually takes.

In the first release

The resources and actions the first consumer needs, end to end
Authentication, scopes, and rate limits per consumer
Validation, error responses, and an audit of calls
Documentation and a sandbox the consumer can test against
Monitoring of usage, errors, and latency

Usually later

Webhooks for the events consumers poll for
Additional consumers and scopes
A developer portal where the number of consumers justifies it

Systems it may connect

Built to work with what you already run.

Your applications and databases
ERP, accounting, and CRM systems with APIs
Payment, shipping, mapping, and messaging services
Identity providers and API gateways
Partner and customer systems
Monitoring and logging tools

How we build it

REST or GraphQL as the consumers need, built in TypeScript on Node.js with OpenAPI documentation and deployed through a tested pipeline. For an existing product we work in its stack.

Product distributor

A large customer sends orders by API, and the order desk no longer keys them from spreadsheets.

When a distributor’s largest customers send orders as spreadsheets attached to email, someone on the order desk keys every line into the order system. An ordering API gives that customer its keys, validates each order against current products and customer pricing, and returns order status, with a webhook when a shipment leaves. Documentation and a sandbox let the customer’s developers test before anything goes live. Once the first customer sends orders directly, the same API can open to other accounts with separate scopes and rate limits.

Where this shows up

Industries where we do this work.

Examples, not a closed list. We take substantial projects from independent businesses in other industries too.

Logistics and distribution businesses

Orders, stock, and shipment status that agree across the ERP, the warehouse, and the carriers, so customers see where their order is without calling.

Software companies

Ship the integration customers keep asking for, the mobile client, or the modernization your roadmap has no room for, while your engineers stay on the current release.

Private equity portfolio companies

Software across the hold period, with a portfolio assessment for the fund and a delivery path for each company.

Another industry entirely

Describe the workflow and the systems around it. Fit depends on the work and the stakes, not the sector.

In plain terms

What is API development?

API development is the design and construction of the interfaces through which software talks to software: the resources, actions, rules, and security that let one system use another without a person in between. API integration is building on someone else’s interface.

The interface is a promise to its consumers. The work is as much contract, documentation, and versioning as it is code, and it belongs with the system that owns the records.

Questions

Questions about API development and integration.

What buyers ask before a project starts, answered plainly.

Do we need an API or an integration?

You need an API if a named customer, partner, or system must build on your data. You need an integration if two systems you run must share records, and it may use an API underneath. The first call sorts it out.

How do you keep it secure?

Each consumer gets its own keys or tokens and scopes that limit what it may see and do. We add rate limits, input validation, and an audit of calls, and review security in every release.

What about a vendor API that changes?

We inspect the vendor’s versioning and support before agreeing on the scope, build with retries and exceptions, and monitor for changes so a failure is visible before a customer sees it.

Will you write the documentation?

Yes. A reference and a sandbox are part of the first release. An API without documentation generates support calls instead of integrations.

Can our customers self-serve keys?

Where the number of consumers justifies it, a developer portal comes in a later release. For a handful of partners, keys are issued by your team from an admin view.

Who runs it afterwards?

Your team runs it, with monitoring and a runbook. When partners ask for the next endpoint, it becomes its own scope.

Scope an API project.

Tell us about the work and the systems around it.
We’ll come back with a written scope for a first release.