← All expertise

02

APIs, data and integrations

An integration doesn't fail when the vendor answers 500. It fails when it answers 200 and does nothing, or when it sends the same event twice. That is where I start designing APIs.

The contract comes before the code

Every endpoint declares a schema at the boundary: what comes in is validated before it touches any logic, what goes out is documented in OpenAPI. The type is not a comment, it is a check that runs at runtime.

The payoff shows up on integration day: instead of discovering fields by trial and error, there is a document stating what arrives and what comes back — and a test that fails when someone changes it.

Idempotency, retries, and the safety net

Webhooks arrive twice, out of order, or never. Every state-changing operation is written so it can be repeated without harm, and every queue has a retry ceiling with growing backoff.

When a vendor's webhook proves unreliable you don't beg it: you put periodic polling beside it to realign state. It costs little and removes a whole class of support tickets.

Making unwilling systems talk

Business systems with XML-RPC APIs from the 2000s, social platforms exposing a slice of what you need, chains whose events must be read block by block: the work is a layer that normalises all of it into one data model, and keeps each vendor's quirks in a single place.

Portfolio

What I did on this, project by project.

Manora

API of the Layer 2 blockchain platform

  • REST API on Express and Prisma with Swagger docs, Zod validation at the boundary, Redis-backed rate limiting and Prometheus metrics exposed for scraping.
  • The indexer as a separate worker: it follows the chain's blocks, rebuilds transactions and balances in PostgreSQL and can resume from where it stopped.
  • Multilingual transactional notifications to the mobile app through Firebase, generated from indexer events rather than from the write path.
  • Express
  • TypeScript
  • Prisma
  • PostgreSQL
  • Redis
  • ethers.js
  • Zod
  • Swagger
  • Prometheus

BigFishIta

Public APIs and social integration

  • Read-only public APIs for blog and company profile with a per-company key: they let external automations read the content without opening the database.
  • Integration with the LinkedIn publishing platform: inbound webhooks with defensive mapping over the two payload shapes the vendor alternates, plus a five-minute poll that realigns post status and comments when the webhook goes quiet.
  • A job queue in PostgreSQL using FOR UPDATE SKIP LOCKED claims and retries, drained both by cron and opportunistically after each insert.
  • Next.js Route Handlers
  • Drizzle
  • PostgreSQL
  • webhooks
  • cron
  • Zod

CocoonServer

Management console for Odoo instances

  • API routes always behind a typed authorisation middleware (user, admin, super admin): auth is never rewritten by hand per endpoint, so it cannot be forgotten.
  • Long operations (environment deploys, module imports) streamed to the browser over SSE instead of a request that times out.
  • Typed application errors, with user-facing messages kept separate from technical logs.
  • Next.js
  • TypeScript
  • Prisma
  • Zod
  • SSE
  • Kubernetes API

Need this?

Tell me the problem and I'll tell you how I would tackle it — and if it isn't worth doing, I'll tell you that too.

Let's talk