Architecture overview

Active Reach runs on a cellular poly-regional architecture designed for data isolation, low latency, and horizontal scaling. Understanding the topology helps you integrate correctly.

The account model that the topology partitions is:

Organization (brand portfolio holder, usually one brand)
  └── Workspace (brand-tenant; one per brand)
        ├── Location[] (outlet — first-class, per-store ops)
        └── Property[] (SDK install — web app / mobile app / kiosk)

Cells partition by tenant (brand). The 2026-05 hierarchy revision made Location first-class — outlets are now an attribute of a brand-tenant rather than separate tenants — but the cellular boundaries are unchanged: a workspace’s data still lives in exactly one cell. See data model.

Two-plane model

The platform is split into two planes:

Control Plane (global)

A single global service that handles:

• Tenant management — organizations, workspaces, billing
• Channel provisioning — WhatsApp, Email, SMS, RCS, Push credentials
• Integration catalog — Shopify, CRM, analytics connectors
• Template management — message templates across channels
• Admin operations — platform health, compliance, provider switching

The control plane does not store contact data or event data. It stores tenant configuration only.

Base URL: https://api.active-reach.ai

Cell Plane (regional)

Per-region isolated environments that handle:

• Contact data — all contact profiles and properties
• Event data — every tracked event, delivery receipt, and engagement signal
• Campaigns & journeys — creation, execution, and delivery
• Segments — real-time segment evaluation
• Analytics — aggregation, funnels, cohorts, insights

Each cell runs in a specific region (India, US, EU, APAC). A workspace’s data lives in exactly one cell and never leaves that region.

Base URL: resolved dynamically per workspace (the control plane returns it during tenant resolution)

Gateway

The Active Reach Gateway sits in front of both planes and handles:

• Write key authentication — validates SDK write keys and resolves which cell a request should route to
• Rate limiting — hierarchical limits per workspace, per channel, per endpoint
• Cell routing — transparently proxies requests to the correct cell based on the tenant’s assignment

When the Web SDK sends an event to https://ingest.active-reach.ai, the gateway:

1. Extracts the write key from the Authorization header
2. Looks up the workspace’s cell assignment (cached in Redis)
3. Forwards the event to the correct cell

How to choose which API to call

What this means for you

• Data residency is guaranteed — your contacts and events stay in the region you chose during onboarding
• The gateway handles routing — you don’t need to know which cell your workspace is on; the SDK and API resolve it automatically
• Two base URLs — if you’re calling the API directly (not via the SDK), resolve your cell URL first via the control plane

SDK extensibility — typed plugin registry

Third-party integrations extend the Web SDK through a typed PluginRegistry rather than ad-hoc hook subscription. Plugins implement a Plugin interface with lifecycle hooks (init, beforeEventCapture, afterEventCapture, beforeBatchSend, afterBatchSend, onError, destroy) and register via Aegis.use(plugin). Hooks run in registration order; a beforeEventCapture hook that returns null suppresses the event entirely.

This is the registration path the first-party Meta Pixel plugin uses, and the same path any custom integration plugin should target. See Web SDK → Plugin registry.

What’s next

• Data model — contacts, events, campaigns, journeys, segments
• Event governance — how the platform manages event quality and volume