NEXUSADTECH
Sign inBook a demo

Technology architecture

Modular where it matters.
Connected where it counts.

Nexus separates operator experience, commercial policy, channel execution and customer infrastructure. The boundaries are deliberate, but the full request-to-evidence path stays understandable.

Across the Nexus suite

Open standards. Your own platform.

IAB Tech Lab

OpenRTB

2.4 / 2.5 / 2.6 configuration

Connect exchange and demand partners with version selection, auction settings, bid floors and timeouts in the RTB module.

OpenRTB specification
IAB Tech Lab

VAST

Video ad serving

Manage video channels and VAST tags. Review starts, quartiles, completions and URI diagnostics in the video module.

VAST specification
AI connectivity

Full MCP

A structured interface for AI clients

Connect compatible assistants to discover tools and work within authenticated, domain-scoped operational boundaries.

Explore AI + MCP
Your operating model

White-label

Your brand. Your domains.

Build your partner-facing experience around your identity, enabled products and agreed deployment requirements.

Explore white-label

Protocols apply to the relevant Nexus modules. Supported versions, player compatibility and partner interoperability are confirmed for your integration. References to IAB Tech Lab standards do not imply certification or endorsement.

System design

A control plane above your revenue infrastructure.

Each tenant can carry its own domains, modules, data sources, Redis services, limits and endpoints. Protected workflows connect that configuration to channel services without exposing infrastructure credentials to the browser.

01

Experience layer

Purpose-built surfaces for public discovery, member visibility and protected system administration.

  • Public product and technical content
  • Role-aware customer workspace
  • Bounded administrator workflows
02

Control layer

The tenant, identity and policy boundary that turns commercial rules into explicit configuration.

  • Platform modules and service URLs
  • Account roles and assignments
  • Routing, limits and connection policy
03

Revenue engines

Channel services that evaluate traffic using the relevant delivery and commercial contract.

  • Search and feed orchestration
  • OpenRTB and VAST workflows
  • CPA, CPI and CPL operations
04

Data & infrastructure

Deployment-specific stores, realtime state and reporting services kept behind server-side access boundaries.

  • MongoDB and SQL data services
  • Restricted Redis application records
  • External reporting and operational APIs

Request lifecycle

Fast decisions still need visible boundaries.

The exact handler changes by channel. The sequence below is the common engineering contract used to keep routing and failure behaviour reviewable.

01

Accept

Receive a request through its documented browser, API, feed, OpenRTB, VAST or postback contract.

02

Validate

Normalize identifiers, URLs, schemas, account context and bounded request fields before routing.

03

Authorize

Resolve the tenant, account, assignment, module and service state allowed to participate.

04

Decide

Apply channel-specific quality, commercial, cap, timeout and destination policy.

05

Record

Retain the safe delivery, error and outcome dimensions required for operations and audit.

Four integration surfaces

Use the interface that matches the job.

01

Human operations

Browser workspaces separate member visibility from system administration and expose only the platform scope assigned to the current identity.

  • Google-verified identity
  • Role and assignment checks
  • 2FA-capable sessions
02

Traffic protocols

Channel services connect through explicit XML, JSON, HTTP, OpenRTB, VAST and postback contracts rather than dashboard-only integrations.

  • Schema normalization
  • Bounded timeout policy
  • Protocol-specific diagnostics
03

Data services

Application services reach approved databases, Redis records and reporting endpoints while credentials remain outside public and member clients.

  • Server-side secrets
  • Source-qualified connections
  • Restricted key contracts
04

AI clients

Compatible assistants discover typed Nexus tools, resources and prompts over Streamable HTTP MCP instead of inferring operations from page text.

  • Runtime capability discovery
  • Structured product context
  • Separate public and privileged boundaries

Security by design

Access, secrets and infrastructure stay on the correct side of the boundary.

These are implemented application controls, not a substitute for the deployment-specific security review, SLA or data-processing agreement.

Review the complete security model ↗
  • HTTP-only authenticated sessions and trusted-origin checks
  • Database role, configured-admin and platform-assignment authorization
  • Server-side database, Redis and external-service credentials
  • Normalized, bounded platform and traffic configuration
  • Restricted remote Redis application-record contracts
  • Audited sensitive account and administration events
  • TLS-verified outbound requests with redirect and destination policy
  • No public claim of unverified certification, uptime or outcome metrics

Design the correct boundary

Map Nexus around the systems and responsibilities you already operate.

Explore integration contracts ↗