Total Access Docs

Architecture

Overview of the Total Access platform architecture and integration points.

Architecture

Service topology

                    ┌─────────────────────────────────────┐
                    │       Edge / CDN (DNS + WAF)         │
                    └──────────────┬──────────────────────┘

                    ┌──────────────▼──────────────────────┐
                    │      Web Application Frontend        │
                    │   Client Zone / Marketing / Admin     │
                    └──────┬───────────────┬──────────────┘
                           │               │
            ┌──────────────▼──┐    ┌───────▼──────────────┐
            │  API Gateway     │    │  Real-time Server     │
            │  (REST + WS)     │    │  (live updates)       │
            └──────┬───────────┘    └──────────────────────┘

     ┌─────────────┼─────────────┐
     │             │             │
┌────▼───────┐  ┌─▼──────────┐  ┌─▼──────────┐
│ Relational  │  │ Document   │  │  Job Queue  │
│ Database    │  │ Store      │  │  (async)    │
└─────────────┘  └────────────┘  └────────────┘

     ├──────────────────┐
     │                  │
┌────▼──────┐    ┌─────▼──────┐    ┌──────────────┐
│  Email     │    │  Voice /   │    │  WebRTC       │
│  Service   │    │  Telephony │    │  Media        │
└───────────┘    └────────────┘    └──────────────┘

Data layers

Relational database (primary)

All transactional data — work items, finance records, contacts, users, attendance data, and integration configuration — is stored in a relational database with row-level tenant isolation.

Document store

A document-oriented store handles audit logs, analytics snapshots, file metadata, and real-time activity streams.

Authentication flow

Token-based authentication

Users authenticate with email and password to receive a short-lived access token and a longer-lived refresh token. Refresh tokens are single-use and invalidated if reused.

Refresh token rotation with reuse detection protects against token theft.

API key authentication

API keys can be passed in two headers:

  • Authorization: Bearer <key> (standard)
  • X-API-Key: <key> (Public Data API)

Each key is validated for activity, expiry, IP allowlisting, and required scopes before the request is processed. Scopes support wildcard matching (e.g. finance:* matches all finance scopes).

API key validation supports wildcard scope matching.

Webhook delivery pipeline

Outbound webhooks

When an event matches a webhook configuration, the payload is cryptographically signed and sent via HTTP POST to the configured endpoint. Failed deliveries are retried automatically. Each attempt is recorded for auditing and debugging.

Inbound webhooks

External systems POST to the inbound webhook endpoint. The request is authenticated (API key or signature), validated, processed according to its type, and logged.

Background job queue

An asynchronous job queue handles background work such as email delivery, video rendering, outbound webhook dispatch, document processing, and notifications.

Multi-tenancy

Total Access uses a multi-tenant architecture:

  • Each client (organization) has isolated data scoped by client_id
  • Users can belong to multiple clients via user_client_memberships
  • API keys are scoped to a single client
  • JWT tokens contain the active client context
  • Module permissions are per-client per-user

Security practices

The platform employs defence-in-depth across edge, network, application, and data layers. Key practices include:

  • Edge protection: CDN-level DDoS mitigation and WAF
  • Authentication: Token rotation with reuse detection
  • API keys: Scoped permissions, IP allowlisting, expiry, and audit trail
  • Webhooks: Cryptographic signatures for payload integrity
  • Rate limiting: Per-tier limits with burst capacity
  • Secrets management: Centralized encrypted secret storage with rotation

On this page