Introduction

Binoban is an enterprise customer data and experience platform (CDXP). It collects and unifies your customers' data into a single profile — the job a customer data platform (CDP) does — and adds the tools to act on that profile, from messaging to advertising, in one platform.

You run it your way. Binoban is white-label and deploys to the cloud, your own servers (on-prem), or a fully air-gapped network — the same integration code, under your brand, on your infrastructure.

This is the developer documentation: how to wire your apps, sites, and backends into Binoban. Business teams who operate the panels are covered by the product manual, which isn't part of this site.

What you'll build

Every Binoban integration starts in the same place — tracking — and then branches into one or both activation paths, depending on what your business needs.

  your app · site · backend
            │
            │   identify() → who they are     ← Web SDK · Native SDK · REST
            │   track()    → what they do
            ▼
  ┌──────────────────────────────┐
  │     Track customer data      │   the foundation —
  └───────────────┬──────────────┘   unified customer profiles
                  │
         ┌────────┴─────────┐
         ▼                  ▼
  ┌──────────────┐   ┌────────────────────┐
  │    Engage    │   │    Retail Media    │
  │  push ·      │   │  1. sync catalog   │
  │  web push    │   │  2. serve & rende  │
  └──────────────┘   └────────────────────┘
   reach customers     run your own ad network

The foundation: track customer data

Everything downstream depends on good data flowing in. Tracking has two halves:

• identify — who the customer is. Associate a user with the traits you know about them (name, email, plan). This is also what links a person's earlier anonymous activity to their known profile.
• track — what the customer did. Record an event (an action) with properties describing it — for example product_added with { sku, price }.

You can send both two ways, and you can mix them:

Path	You use	Best for
Client-side	Web SDK · Native (Android/iOS) SDK · React Native	In-app and on-site behaviour, identity, page/screen views
Server-side	Tracking REST API	Trusted events from your backend — orders, payments, server-side state

→ Send your first event in the Quick Start, or read Track customer data for the full picture.

Then activate: Engage, Retail Media, or both

Once profiles and events are flowing, you turn them into outcomes. Two activation paths build on the same data — adopt either, or both:

• Engage — reach customers on their channels. Deliver push and web-push messages triggered by the behaviour you track. Your job as a developer is to wire up the channels and keep events flowing; business teams design the campaigns and journeys. → Activate Engage

• Retail Media — run your own retail media network. Turn your storefront into an advertising platform where your sellers and brands promote products to your shoppers — a white-label network you own end to end. It's two developer jobs:

  1. Sync your catalog — feed products, variants, and categories in through the Catalog and Sync APIs (a backend task).
  2. Serve & render ads — request and display ads in your slots, from your backend API or the SDK.

  → Activate Retail Media

Where the developer's job ends

Across Engage and Retail Media, your job is to instrument well — send clean, well-named events and keep your catalog current. Audiences, campaigns, pricing, and reporting are configured by business teams in the panels. Name your events and traits deliberately: they are the contract everything downstream relies on.

Choose your starting point

If you want to…	Go to
Get a first event flowing in ~20 minutes	Quick Start
Understand the data model before you code	Concepts
Set up credentials and hosts	Authentication & setup
Track from a website	Web SDK
Track from a mobile app	Android · iOS
Track from your backend	Track from your backend
Message customers (push / web push)	Activate Engage
Build a retail media network	Activate Retail Media

How these docs are organized

The developer docs are grouped by the job you're doing, not by SDK versus API:

• Quick Start — a first event flowing in ~20 minutes.
• Concepts — how Binoban's model fits together (the why), including Authentication & setup — credentials and hosts, shared by every path.
• Track customer data · Activate Engage · Activate Retail Media — the integration jobs, each pairing the SDK and REST options, with a task-shaped how-to per SDK.
• How-to guides — cross-cutting recipes.
• Reference — exhaustive lookup, split into SDKs, APIs, Event spec, and Ops.

New here? Start with the Quick Start.