Set up ads.txt and sellers.json
ads.txt on your domain and your entry in Genuin's sellers.json tell buyers that Genuin, and any partner ad server you use, are authorized to sell your inventory; without them most programmatic demand will not bid. Reading time about 5 minutes.
What BCC generates
Under Monetize → Sellers, BCC produces the exact lines for your domain and, if you have apps, for app-ads.txt. Each line names the seller domain, your seller account ID, the relationship (DIRECT or RESELLER), and the certification authority ID. Your entry in Genuin's sellers.json is created automatically from your legal entity in Choose your monetization agreement.
Steps
- Copy the generated lines.
- Publish them at
https://yourdomain.com/ads.txt(append if the file exists). For apps, publishapp-ads.txton the developer website listed in the app store. - If your site cannot host a root file, choose Use DNS redirect and add the CNAME BCC shows.
- For partner ad servers, add the lines that platform gives you as well; both sets must be present.
- Choose Verify. BCC crawls, validates syntax, and shows any missing or duplicate lines.
Keeping it current
BCC re-crawls daily and alerts the Revenue role (see Invite your team and assign roles) if a line disappears. Adding a demand partner (see Add brand partners and demand partners) that sells your inventory adds a line; BCC shows the diff for approval.
Common errors
| Error | Fix |
|---|---|
| 404 on /ads.txt | Publish at the root, not in a subfolder; check CDN caching |
| Wrong relationship | Use the relationship BCC shows; do not change RESELLER to DIRECT |
| Subdomain mismatch | ads.txt lives on the root domain; subdomains inherit it |
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 |
|---|---|
| GET /brands/{brandId}/seller-files | ads.txt, app-ads.txt, and sellers.json lines per domain and app, with verification state |
| POST /brands/{brandId}/seller-files:verify | Re-crawl and validate seller files |
// proposed server SDK (Business Account API)
import { Genuin } from '@genuin/sdk';
const genuin = new Genuin({ apiKey: process.env.GENUIN_KEY });
await genuin.sellerFiles.get(brandId);
await genuin.sellerFiles.verify(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.
