NEXUSAD PLATFORM

Integrations

Connect Nexus to the systems that already run your business.

Map each connection as a controlled exchange: what moves, in which direction, under whose authority, within which limits and with what evidence when it succeeds or fails.

Available now

Available integrations and self-serve workflows.

Cookie sync, Popunder JS, XML direct links, multi-format advertiser campaigns, self-serve account management, Push Subscribers, Prebid.js and Prebid Server are available today.

Cookie sync

Cookie sync is available now in OpenRTB. Configure UID macros and image or iframe sync URLs, then review synced requests in RTB reporting.

Partner configuration and browser cookie restrictions still apply. Cookie sync and Prebid are separate integrations, each with its own configuration requirements.

Explore OpenRTB ↗

Prebid.js and Prebid Server

Prebid.js and Prebid Server integrations are available now for Nexus OpenRTB. Connect header-bidding workflows to your configured RTB supply and demand setup.

Confirm the supported versions, bidder adapter, endpoint configuration and inventory formats for your deployment. Partner access and commercial agreements are configured separately; availability is not a guarantee of compatibility with every adapter or demand partner.

Explore Prebid and OpenRTB ↗

Popunder JS

Popunder JS support is available now in the XML / JSON module, with publisher script configuration, frequency and delay settings, feed routing and source controls.

Use a permitted publisher placement and suitable demand. Confirm the script version and any provider licensing requirements for the deployment. Browser restrictions determine whether and how a secondary window can open; support is not a browser-bypass guarantee.

Explore Popunder JS ↗

Direct links

Direct link support is available now in the XML / JSON module. Route publisher traffic through the configured XML demand and destination workflow, with source controls and click reporting. This is an XML capability, not the CPA offer module.

Use approved traffic sources, configured XML demand and a working destination. A direct link does not itself create a popunder. Do not assume CPA conversion or payout rules apply to XML direct links.

Explore direct links ↗

Advertiser self-serve

Advertiser self-serve is available now for direct advertisers. Advertisers can manage their campaigns, creatives, targeting, budgets, funds and account balance in the advertiser workspace, with reporting and operator-defined access.

Funding methods and payment-provider configuration depend on the deployment. Funds and balance management do not imply a particular payment gateway, instant settlement or public access to account balances.

Explore advertiser self-serve ↗

Multi-format direct campaigns

Multi-format direct campaigns are available now for direct advertisers: display and HTML banners, native and contextual ads, video, popunder, Web Push and in-page push. Manage CPC (cost per click) and CPM (cost per thousand impressions) buying models, with delivery across Push, XML / JSON and OpenRTB traffic. Campaigns, creatives, targeting and budgets stay in the advertiser workspace.

CPC and CPM describe media buying, not the Nexus capacity subscription. XML / JSON and OpenRTB are delivery integrations, not creative formats. Match each campaign to compatible inventory, creative assets, tracking and, where required, a player or publisher renderer. Web Push requires permission and valid subscriptions.

Explore direct advertiser campaigns ↗

Push Subscribers

The Push Subscribers module is available now for direct publishers. Manage publisher websites, browser subscriptions, subscriber inventory, subscription settings and notification activity with publisher reporting.

Web Push requires browser permission, valid subscriptions and configured website and delivery services. It is distinct from an in-page push ad; a publisher record alone does not enable delivery.

Explore Push Subscribers ↗

Integration catalog

Protocols, data services and people belong to one operating map.

The list below describes supported integration families, not a promise that every external product connects without design work. Exact schemas, versions and ownership are confirmed during discovery.

01

Traffic & delivery

Move advertising opportunities and responses through the protocol each channel expects.

  • XML and JSON feeds
  • HTTP service APIs
  • OpenRTB endpoints
  • Prebid.js and Prebid Server
  • Cookie sync
  • VAST demand and delivery
  • Popunder JS
  • Direct links
DATA IN CONTRACT
Requests, targeting context, bid or result data, delivery status and protocol errors.
BOUNDARY
Schemas, URLs, timeouts, result limits and eligible routes are explicitly configured.
02

Data & reporting

Connect commercial records and operational evidence without making the browser a database client.

  • MongoDB
  • MySQL
  • TimescaleDB / PostgreSQL
  • External reporting services
DATA IN CONTRACT
Platform records, aggregated statistics, partner mappings and approved reporting dimensions.
BOUNDARY
Connections are source-qualified, credentials stay server-side and returned data is bounded.
03

Realtime infrastructure

Reach the fast-changing state used by delivery services while keeping key access deliberately narrow.

  • Redis application hashes
  • Tenant load balancers
  • QPS and rate controls
  • Service health state
DATA IN CONTRACT
Approved application configuration, limits, availability and safe operational status.
BOUNDARY
Only documented Redis records are in contract; unrelated keys and queues remain outside it.
04

Identity & operations

Give people and connected platforms the correct scope before any privileged workflow begins.

  • Email/password and Google member registration
  • Google-only administrator sign-in
  • SMTP or Resend account email
  • Platform-level assignments
  • Audit events
DATA IN CONTRACT
Verified identity, role, platform scope, session state and bounded administrative evidence.
BOUNDARY
Registration grants no platform access or administrator role; protected requests re-check current account status, role and assigned scope.
05

Performance tracking

Join an acquisition event to the offer, source and partner economics responsible for it.

  • Server-to-server postbacks
  • Conversion identifiers
  • Campaign and offer APIs
  • External tracking services
DATA IN CONTRACT
Click identifiers, event names, conversion values, status and reconciliation context.
BOUNDARY
Accepted fields, event ownership, retry behaviour and deduplication rules are agreed in advance.
06

AI & developer discovery

Expose stable public product knowledge and documented interfaces to software clients.

  • OpenAPI document
  • Streamable HTTP MCP
  • llms.txt discovery
  • Typed tools and resources
DATA IN CONTRACT
Product capabilities, schemas, format guidance and bounded solution-discovery context.
BOUNDARY
Public discovery does not expose customer credentials, arbitrary queries or privileged writes.

Development roadmap · Updated 11 September 2026

Further modules and integrations

Available capabilities are listed above. The development roadmap covers additional planned modules and integrations, not capabilities already released. Confirm the scope and timing of a specific upcoming feature with the team.

Prebid.js and Prebid Server, cookie sync, Popunder JS, XML direct links, multi-format direct campaigns, advertiser self-serve and Push Subscribers are already available. The remaining planned modules and integrations are in development, with a target of 10 December 2026 under the plan confirmed on 10 September 2026. Ask the team to confirm whether another specific missing feature is in scope and when it will be available.

This is a development target, not a guaranteed delivery date or an SLA. Confirm release status, supported versions and the exact integration scope before planning a launch. The broader goal is full support for the planned modules and integrations; it is not a promise to support every third-party product or arbitrary requested feature.

From endpoint to evidence

A connection is ready only when failure is designed too.

Happy-path connectivity is one step. Production readiness also requires bounded input, dependency behaviour and a shared way to reconcile what happened.

01

Contract

Define owner, direction, authentication, schema, volume range and expected response.

02

Sample

Use representative payloads with secrets and personal data removed or safely substituted.

03

Connect

Configure the endpoint, source, credentials reference and tenant policy server-side.

04

Exercise

Test valid, empty, slow, malformed, duplicate and unavailable-path behaviour.

05

Reconcile

Confirm which metrics, logs, errors and commercial records prove correct operation.

Bring this to technical discovery

The six facts that shorten integration design.

01

Ownership

Named technical and commercial owners on both sides of the connection.

02

Direction

A clear record of what Nexus sends, receives, stores and never exposes.

03

Authentication

Documented credential type, rotation owner and safe secret reference.

04

Capacity

Expected and maximum request ranges, timeout budget, caps and retry policy.

05

Failure

Agreed behaviour for empty data, partial response, dependency failure and recovery.

06

Evidence

The fields and reports used to validate delivery and reconcile partner totals.

A deliberate boundary

Connected does not mean exposed.

Infrastructure credentials remain server-side. Remote Redis access is restricted to documented application records. Tenant configuration and remote destinations are validated before they reach service and data layers.

Map the real contract

Bring one representative traffic path and we will identify the required boundaries.

Start an integration discovery ↗