Programmatic: Genuin Ad Server or your partner ad server
Programmatic demand serves into your placements through either Genuin Ad Server, which comes connected to exchanges and needs no setup beyond seller authorization, or your own partner ad server, which stays the system of record and receives Genuin's inventory as line items. Reading time about 7 minutes.
Choose your path
| Genuin Ad Server | Partner ad server (GAM, FreeWheel, Beeswax, others) | |
|---|---|---|
| Pick it when | You want demand without ad ops, or have no ad server | Your ad server already holds your direct deals, priorities, and reporting |
| Who traffics | Genuin ad operations configures tags per placement | Genuin ad operations configures your ad server's tags inside Genuin Ad Server for the specific placements |
| Floors and pacing | Set in BCC per placement | Set in your ad server; BCC mirrors them |
| Reporting | BCC along the grid | Your ad server plus BCC reconciliation |
| Setup time | Same day once sellers verify | Three to ten business days |
Path A — Genuin Ad Server
- Verify sellers (see Sign your agreement and authorize sellers).
- In BCC open Monetize → Programmatic and choose Genuin Ad Server.
- Set floors per placement (or accept the proposed floors from your brand safety profile) and choose which exchanges and deal types are allowed (open auction, PMP, programmatic guaranteed).
- Genuin ad operations generates and places the tags. Impressions appear in Reports → Revenue the same day.
Path B — Partner ad server
- Verify sellers (see Sign your agreement and authorize sellers) and add your ad server's seller entries to
ads.txtas well. - Choose Partner ad server, pick the platform, and export the placement CSV from the grid (see The Hierarchical Grid: one spine for inventory, layout, and reporting); it maps one to one to ad units or line items.
- Create the ad units in your ad server and paste their tags into BCC per placement. Genuin ad operations configures them inside Genuin Ad Server for those placements.
- Set priorities in your ad server as usual; Genuin demand fills what your server passes back.
Both paths
- Blocklists and ad quality (see Blocklists and ad quality controls) apply before any ad renders.
- Viewability, brand safety profile, and context are passed in the bid request through standard IAB fields (see Ad tag reference: VAST, IAB sizes, and macros).
- Audience extension: your cohorts (see Audience segments: onsite, offsite, and offline signals) can be targeted on offsite inventory through the same exchanges at programmatic CPMs.
How it runs
The demand setup, packages, agreements, and seller files described here are drafted for you, priced against your floors and brand safety profile, and switched on only with your approval; money never moves on a change you did not approve.
Support. Help is available 24/7 from Brand Control Center and from every page of these docs. Ask in plain language; when a person is needed, an account manager, developer, or Ops engineer joins the same thread and stays on it until it is resolved. Every Business Account owner has this on every plan (see 24/7 Octo-enabled support: how Octo brings in account managers, developers, and Ops).
API & SDK
Access: the calls in the table are the proposed Business Account API (see Business Account API: provisioning, OAuth, and the resource map), authenticated with a key scoped to the account and a role or an OAuth client acting for it; every confirmation in this article becomes a proposal you can approve by API (POST /proposals/{proposalId}:approve). Live today, the server API under /api/thirdparty authenticates with a gn-access-token (see Generate an access token), and Live API today and the Business Account API roadmap maps what is live to what is proposed.
| Call | Purpose |
|---|---|
| PUT /brands/{brandId}/ad-server | Genuin Ad Server or partner ad server connection, floors, and yield rules |
| POST /demand-sources/{sourceId}:activate | Switch a demand source on (or off) in order |
| GET /brands/{brandId}/seller-files | ads.txt, app-ads.txt, and sellers.json lines per domain and app, with verification state |
// proposed server SDK (Business Account API)
import { Genuin } from '@genuin/sdk';
const genuin = new Genuin({ apiKey: process.env.GENUIN_KEY });
await genuin.adServer.update(brandId, { provider: 'gam', floors });
await genuin.demand.activate(sourceId);
await genuin.sellerFiles.get(brandId);Live today: Serve your first ad.
SDKs: Web SDK 2.0.6 (see Embed the Genuin Web SDK on your website), iOS SDK 2.1.5 (see Integrate the Genuin iOS SDK), Android SDK 2.1.5 (see Integrate the Genuin Android SDK), React Native 3.0.3 (see Integrate the Genuin SDK with React Native apps), and Flutter (see Integrate the Genuin SDK with Flutter apps) render Genuin and sign members in; the Node (@genuin/sdk) and Python (genuin) server SDKs are proposed with Business Account API: provisioning, OAuth, and the resource map.

