API DEVELOPMENT
APIs for your own product and integrations for systems that were never designed to talk to each other.
TWO KINDS OF WORK
01
Creating the interface other software uses to reach your system: the layer behind a mobile app, web front end, or customer integration. The hard part is design, because changing a published API after people depend on it is painful.
02
Connecting to a service you do not control. The hard part is defence: incomplete documentation, unclear rate limits, changing responses, expiring tokens, and outages at inconvenient times.
Most product work includes both. The delivery approach changes depending on which problem is creating the risk.
WHAT I BUILD
The work covers the API itself, the integrations around it, and the operational details that keep the data flowing once nobody is watching.
Versioned, documented interfaces with consistent responses, sensible errors, and a structure other teams can rely on.
The API layer behind a React Native product, including authentication, sync, and offline-aware data behaviour.
Payments, CRM, email, calendars, storage, shipping, accounting, and the systems your product needs to use.
Reliable data exchange between two platforms that both matter to a business but were never designed to talk.
Consuming and providing event notifications with retries and idempotency that make them safe to trust.
OpenAPI specifications and readable documentation so the next integrator does not need to reverse engineer the code.
INTEGRATION REALITY
Integration estimates go wrong more often than any other kind because the unknowns are not visible until you are inside the third-party system. Documentation can differ from reality, a rate limit may not be written down, and the required data model may not fit.
Before quoting, I check the documentation, authentication, sandbox, error responses, rate limits, and whether the system can actually represent what you need. That short review is how a fixed price holds.
“Assess the connection before promising the outcome.”
The operating principle
RELIABILITY
Every external service will fail eventually. The useful question is whether your system notices and recovers sensibly. Retries, backoff, idempotency, timeouts, queues, and actionable logging are part of the implementation.
Without them, orders do not sync, emails do not send, and somebody discovers the problem weeks later when a customer complains.
“A retry should not create a second order.”
COMMON INTEGRATIONS
If yours is not listed, that is normal. The first useful question is whether its API can do what the business needs.
Stripe, PayPal, subscription lifecycle events, and payment status that stays consistent with the product.
HubSpot, GoHighLevel, Mailchimp, lead routing, contact updates, and event-driven follow-up.
Shopify, WooCommerce, orders, stock, product data, and operational systems around the sale.
Twilio, SendGrid, Slack, AWS S3, Cloudinary, and the notifications or files a workflow depends on.
COMMON QUESTIONS
The practical details to settle before two systems start depending on each other.
REST for most projects. GraphQL solves real problems in complex multi-client products, but adds complexity everywhere else.
Sometimes through database access, file exchange, or scheduled imports. Screen scraping is a last resort and I will explain how fragile it is.
A well-documented API with a sandbox can take days. A poorly documented system with unusual authentication can take weeks. The pre-quote review finds out which.
Yes. I can read the implementation and produce an OpenAPI specification plus documentation people can actually use.
It happens. Versioned integrations and error alerting ensure you find out promptly, not through a customer complaint.
Yes, including authentication, versioning strategy, rate limits, webhooks, and documentation.
Tell me what needs to talk to what. For an integration, send the documentation and I will review the risks before quoting.
