Integrations are where data goes missing#
Most businesses run on several systems: a CRM, a payment provider, a shipping carrier, an accounting tool and their own database. The value depends on those systems agreeing with each other. The weak point is almost always the integration: a webhook that fails once and is never retried, a token that expires at 2am, an API that changes its response format, or a sync nobody is watching until a customer complains.
I build integrations on the assumption that those failures will happen. Every external call has a timeout, every failure is retried or recorded, and every important sync leaves a trail you can inspect. When something goes wrong, you find out from an alert, not from a customer.
Signs you need better APIs and integrations#
- Your team copies data between systems by hand, and mistakes creep in.
- Integrations break without anyone noticing until reports don't add up or customers complain.
- Customers were charged twice, or not at all, because a payment event was missed or processed twice.
- A partner or mobile app needs an API and your application doesn't have a clean one.
- You rely on a fragile chain of automations that nobody fully understands.
What I build#
REST APIs#
APIs for your frontend, mobile apps or partners: consistent resource design, validation, pagination, rate limiting and meaningful errors. Versioned so changes don't break existing clients, and documented with OpenAPI so developers can self-serve.
Payment integrations#
Stripe SetupIntents for saving cards, PaymentIntents for charges, 3D Secure / SCA, subscriptions and webhooks. Payment state comes from the provider's webhooks, not from the browser, so it can't be spoofed or lost.
CRM and marketing integrations#
GoHighLevel, Zapier and custom CRMs: syncing contacts, deals and activities without creating duplicates. See also CRM & business software.
Logistics and carrier APIs#
Rates, labels, tracking and activation across multiple carriers, behind one consistent interface so your application doesn't care which provider handles an order.
Google and messaging APIs#
Maps and geocoding, calendars, and push notifications through Firebase Cloud Messaging.
Built for failure#
Each integration I build includes:
- Idempotent processing, so a repeated webhook or retried request doesn't double-charge or double-create.
- Retries with backoff for temporary outages, and a queue of failed jobs you can replay once the provider recovers.
- Timeouts on every external call, so one slow provider can't slow down your whole application.
- Signature verification on incoming webhooks, and encrypted storage for credentials and tokens.
- Structured logs and alerts, so a failing sync is noticed the same day, with enough detail to fix it.
- Adapters per provider, so a provider changing its API means updating one class, not the whole codebase.
Integration projects#
- Stripe lead billing: lead-generation clients save a card with a Stripe SetupIntent without being charged, then are billed automatically with a PaymentIntent when qualified leads are delivered from GoHighLevel. Webhooks drive the flow, with a Zapier fallback.
- EXPRECO: shipping quotes calculated from the live UPS and FedEx APIs inside a Laravel and Livewire quoting system.
- Multi-carrier SIM activation: 4+ carrier and MVNO backends unified behind one bulk activation engine, with OpenAPI documentation generated by L5-Swagger.
- ION DASH: Stripe PaymentIntents with 3D Secure, server-side price validation, Google Maps, Firebase push notifications and automated vendor catalog sync.
Common integration mistakes I fix#
- Trusting the browser for payment status. A redirect back from a checkout page proves nothing; only the provider's webhook does.
- Processing webhooks inline. If processing is slow, the provider times out and resends, and without idempotency you get duplicates.
- No timeouts. A provider that hangs for thirty seconds takes your checkout, dashboard or queue down with it.
- Credentials in code or in plain text in the database, instead of encrypted storage and rotation.
- Silent failures. A try/catch that logs nothing, or logs to a file nobody reads, turns a five-minute fix into a week of missing data.
- One integration spread across the codebase, so a provider's API change means edits in dozens of places.
Designing an API others will use#
A public or partner API is a promise. Once other people build on it, every change has consequences. I design APIs with stable resource names, consistent error formats, pagination and filtering conventions, authentication that fits the client (tokens for apps, OAuth for third parties), rate limits, and versioning so the API can evolve without breaking existing integrations. Documentation is generated from the code so it never drifts out of date.
What you get#
- integrations running on your infrastructure, with source code in your repository;
- a data-flow diagram showing which system owns what and how it syncs;
- API documentation generated from the code;
- a dashboard or log view of recent syncs and failures, with alerts to the right person;
- a short runbook for what to do when a provider is down.
Related services#
APIs are usually part of a larger build. See Laravel development, CRM and business software, e-commerce integrations and mobile app development.
Working together#
We start with a free 30-minute call where you walk me through the systems involved and what should happen between them. I map the data flow, flag the failure points, and send a written scope. Integrations run as fixed-scope projects, and ongoing maintenance can be covered by a retainer.
Need systems connected? Book a free call and walk me through the flow.
