Sendy

The problem

Each store on Sendy needs its own delivery partners, payment methods, staff roles, and public storefront, fully isolated from every other store's data, on one shared codebase.

Store capabilities have to be reachable two ways: from Sendy's own dashboards (JWT sessions) and from external systems integrating directly with a store (API keys), both guarded by the same permission model.

Three delivery companies and five payment gateways expose their own APIs and webhook formats, and have to be normalized behind one internal contract without a provider outage or a replayed webhook corrupting order state.

Customers expect real-time order status and support across WhatsApp, Instagram, Messenger, and web chat, routed to whichever AI agent a store has configured, and billed back to that store.

Role & responsibilities

Backend architecture across a 164-controller, 1,120-endpoint ASP.NET Core API, with 64 EF Core migrations for 99 domain entities.

The JWT and API-key authentication surfaces, plus the permission model guarding both: 243 permissions enforced across 701 endpoint checks.

The delivery-provider and payment-gateway integration layer: webhook verification, order sync, and retry handling.

Real-time features over SignalR (order tracking and customer chat) across three hubs.

The AI/MCP surface: omnichannel messaging routed to Claude or OpenAI, and an OAuth-secured MCP server exposing store operations to agents.

812 xUnit test methods backing the API.

Two authentication surfaces, one permission model

Every store capability had to be reachable both from Sendy's own session-based dashboards and from external systems calling in with an API key, without maintaining two separate authorization codepaths that could drift apart. A single permission model (231 named permissions enforced across 679 endpoint checks) is evaluated for both JWT and API-key requests, with API keys additionally scoped and rate-limited per store, so a permission change only has to be made once.

Normalizing delivery and payment providers

Three delivery companies (Al-Waseet, Boxy, Hi-Express) and five payment gateways (QiCard, AsiaPay, ZainCash, Wayl, SwiftPayIQ) each expose different APIs and webhook shapes, and a store can plug in more than one at a time. A pluggable provider framework sits behind one internal contract, with HMAC-verified webhooks, per-store credentials, and EF Core interceptors driving automatic order push and status sync, backed by outbox/retry delivery tracking on Hangfire. Adding or swapping a provider is a configuration and adapter change, not a rewrite of order logic, and webhook failures retry instead of silently dropping order updates.

Omnichannel messaging and AI agents

WhatsApp, Instagram, Messenger, and website chat are normalized into a single conversation model, with each store choosing which AI agent (Anthropic Claude or OpenAI GPT) answers on its behalf, metered per store for billing.

An OAuth-secured MCP server with dynamic client registration exposes a scoped set of store operations as MCP tools rather than the full API surface, so AI agents integrate against a narrow, auditable tool surface instead of broad platform access.

Order tracking in real time

A customer places an order on a storefront or via an integrated channel; it lands in the store's data through the permission-checked API.

EF Core interceptors push the order to the store's chosen delivery provider; provider status changes arrive as HMAC-verified webhooks processed through outbox/retry on Hangfire.

Status updates broadcast over SignalR hubs to the dashboards and to a tokenized public tracking link, so customers see live status without an account and store staff see it on the admin dashboard and driver app.

Outcome

Five React 19 + TypeScript frontends: admin dashboard, driver app, storefront, customer mini-app, and a Next.js developer-docs site, all Arabic/English, running live production operations for delivery and retail businesses in Iraq. The platform spans 164 controllers, 99 domain entities, and 64 migrations, backed by 812 xUnit test methods, with public storefronts on slug subdomains and Cloudflare-verified custom domains.

What I learned

Provider abstraction pays for itself the moment a second provider needs the same capability.

A permission model shared across auth schemes is worth the extra complexity: it's the only way two very different client types don't end up with divergent authorization bugs.

Webhook reliability is a design problem, not an edge case: outbox/retry needs to be there from the start.