CMCarl MannSolutions Architect
Engagement · 04

APIs & integrations.

Surfaces designed to survive the partner who didn't read the spec.

REST, GraphQL, webhooks, and the third-party integrations that hold a product together. Stripe, HubSpot, the CRM your sales team actually uses, the SFTP feed your distributor still ships you on Tuesdays. Designed, documented, versioned -- and resilient when the other end behaves badly.

4-10wk typicalREST · GraphQL · WH100%of payloads logged
What you get

Surfaces that hold together.

The interesting failures in any system live at its edges -- the partner that retries forever, the webhook that arrives twice, the field that mysteriously becomes null on Tuesdays. Integration work is mostly the discipline of expecting that.

01

APIs you can read

Versioned, documented, and consistent -- not the artefact of three sprints stacked on top of each other. OpenAPI or schema-first GraphQL, with the docs generated from the source so they don't drift.

02

Webhooks that retry sensibly

Idempotency keys, exponential back-off, dead-letter queues, signed payloads. Every delivery logged, every failure visible, every duplicate harmless.

03

Integrations that outlive the demo

Stripe, HubSpot, Salesforce, Shopify, the awkward gateway your distributor insists on. Built behind a clear seam, with the partner API isolated -- so when their docs change in six months, only one file moves.

Engagement model

Contract first,
code second.

The hardest part of an API engagement is agreeing on the contract. The hardest part of an integration engagement is figuring out what the partner's contract really is. Both happen before a line is written.

  1. 01

    Contract on paper

    Either you have a spec or we write one. OpenAPI, GraphQL schema, JSON-Schema for webhook payloads -- something that both sides can sign off on before the first endpoint is implemented.

  2. 02

    Mocks before clients

    Mock servers spun up from the contract so consumer teams can start integrating in parallel. Real implementation happens behind the same contract -- no surprises at the join.

  3. 03

    Observability built in

    Structured logs, request IDs, payload capture for the awkward third-party that won't share its outbound logs. Every integration ships with a way to answer 'what did they actually send us?' in under a minute.

  4. 04

    Handed off, not abandoned

    Versioning policy, deprecation cadence, partner-facing changelog. Thirty days of post-launch support included -- and a runbook so the on-call engineer isn't paging me at 3 a.m.

Scope notes

A good fit, and a not-quite-fit.

Good fit

A partnership held together by code.

  • A public or partner-facing API where the contract matters more than the framework.
  • An integration with a third party whose documentation is two versions out of date and whose support emails take a week.
  • Webhooks, sync feeds, daily batch jobs -- the unglamorous plumbing that the rest of the product quietly depends on.
  • A team that values logs and runbooks more than dashboards full of vanity metrics.

Less of a fit

Glue-code with no clear owner.

  • A high-frequency-trading or sub-millisecond latency surface -- that's a specialty practice, not this one.
  • An integration where neither side will agree on the contract until something ships. Won't work; the work is the contract.
  • "Just hook our CRM to our newsletter tool" -- you want Zapier, not a contract.
  • Compliance regimes (PCI level 1, HIPAA in production) where the practice would only be one of several specialists you need.

An API that
outlasts the partner.

Send the existing spec, the failing integration, or the screenshot of the partner's documentation. A reply lands inside 24 hours on weekdays.

Start a Project Booking Q3 2026
© 2026 Carl Mann · All rights reserved · Made by hand on the open web~ delegate the technical ~Set in Instrument Serif, Manrope & JetBrains Mono