Service
API Development and Integrations
APIs designed to be consumed by someone else, and integrations built for the day the other system is slow, down, or sends the same event twice.
The problem
What usually goes wrong
An integration written for the happy path works until the first timeout. Then an order exists in one system and not the other, and someone reconciles it by hand every Monday.
Public APIs fail differently. They are built to serve one internal caller, then a partner needs them, and every undocumented assumption becomes a support ticket.
The engineering that matters is in versioning, idempotency, verification and what happens after a failure.
Scope
What we deliver
API design and specification
Resource model, authentication, pagination, filtering, error format and versioning, written before implementation and published as a specification.
Authentication for machines
API keys or OAuth clients with scopes, rotation, and per client rate limits that return proper status codes rather than dropping requests.
Webhook delivery
Signed payloads, delivery attempts with backoff, a replay endpoint and a log your partners can inspect.
Inbound integration handling
Signature verification, deduplication by event identifier, ordered processing where order matters, and a dead letter queue for what cannot be processed.
Idempotency
Client supplied keys on every write, so a retry after a timeout returns the original result rather than creating a second record.
Documentation and a sandbox
Reference documentation generated from the specification, with examples that run.
Method
Technical approach
The specification comes first and is treated as the contract. Endpoints, payload shapes, status codes and error bodies are agreed before code, which is what makes parallel work on both sides possible.
Every write endpoint accepts an idempotency key. The key, the request fingerprint and the response are stored, so a repeat within the retention window returns the stored response and no duplicate side effect occurs.
Inbound webhooks are verified by signature and timestamp before parsing, then recorded by event identifier. A duplicate is acknowledged and dropped. Processing happens after acknowledgement, so the sender is not held open while your work runs.
Outbound calls are wrapped in a policy: timeout, retry with exponential backoff and jitter, a circuit breaker for a provider that is failing, and a queue for anything that exhausts retries. Failures surface in an operations view rather than a log file.
Versioning is planned from the first release. Additive changes ship inside a version. Breaking changes get a new version with an overlap period and a written migration note.
Handover
Deliverables
Everything below is yours at delivery, including the intellectual property. Sawhorse keeps nothing.
- 01Published API specification with examples
- 02Authentication, scopes, key rotation and rate limiting
- 03Idempotent write endpoints with key storage
- 04Signed webhook delivery with retries and a replay path
- 05Inbound handlers with verification, deduplication and a dead letter queue
- 06Operations view for failed and pending deliveries
- 07Integration test suite including failure simulation
- 08Reference documentation, source code and deployment guide
Related
Systems this service builds
- Payment IntegrationWe integrate your software with processors such as Stripe, Square and Adyen using hosted fields, tokenization and processor managed checkout, which keeps card data out of your systems and reduces your PCI scope.
- Workflow Automation PlatformsAn orchestration layer that runs your cross system processes with retries, visibility and controls, instead of scripts on a laptop and rules in one person email client.
- Inventory and Order ManagementOne stock position and one order lifecycle across every channel, built on a movement ledger rather than a quantity field people adjust.
FAQ
Questions people actually ask
What is an idempotency key and why does every write need one?
It is a value the caller generates for a specific request. The server stores it with the result. If the caller times out and retries with the same key, it gets the original result back instead of creating a second order, charge or record.
How do you verify an incoming webhook?
By recomputing the signature over the raw request body with the shared secret and comparing it in constant time, and by rejecting a timestamp outside a short window so a captured request cannot be replayed later.
What happens when a partner system is down for hours?
Calls fail fast once the circuit breaker opens, work queues, and delivery resumes when the provider recovers. Anything that exhausts its retry budget lands in a queue with the payload and the error, visible to an operator.
Do you work with SOAP, flat files and other older interfaces?
Yes. Plenty of established systems speak SOAP, fixed width files or scheduled file drops. We build an adapter layer so the rest of the system sees a modern interface.
Can you integrate with a system that has no API?
Sometimes, through exports, a database replica, or a file exchange the vendor supports. Where the only route would be brittle screen scraping we say so and describe the risk before you commit.
Who owns the API once it is built?
You do, including the specification, the source code and the documentation.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.