Platform reference
The entry point to the fact pages — which reference answers which question, grouped by what you are looking up (creatives, inventory, targeting, delivery, analytics, ad tags and macros, the UI, the platform's hard limits) with a pointer to the REST API reference.
The guides tell you how to do a task; the reference pages state the facts — every type, option, field, metric and limit, as tables you can look up rather than read. Each page below lists one family of facts exhaustively and links the guide that uses it. If you are not sure which page holds a term, start with the Glossary: every entry names the page that owns the detail.
Example. A publisher asks why a 300×600 creative is not offered on their mobile-site placement. Banner types says which creative types each placement type accepts; Placement types says which editor cards and tags the placement has; Creative ad specs gives the size cap that stops the upload. Three lookups, no guide needed.
Which page answers what
| You are looking up | Page |
|---|---|
| A term, or a word that means two things (Revenue, Charges, Blocked, Rules, Priority) | Glossary |
| The 12 creative types, which placements offer each one, the fields each shows | Banner types |
| The 8 placement types, their ad tags, accepted creatives and editor cards | Placement types |
| Accepted file types, size caps, native asset limits, field lengths per format | Creative ad specs |
| All 43 targeting rule types, their pickers, options and corner cases | Targeting dimension reference |
| The capping enum — types, subjects, periods — and the permission behind each | Capping matrix |
| Every report metric column with its exact formula | Analytics metrics reference |
| Every group-by dimension and filter per report type | Analytics dimensions reference |
| Every ad tag type the platform generates, per-placement availability, default tag parameters | Invocation code types |
Every $$…$$ macro, what it returns when data is missing, which contexts resolve it | Macros |
The /ads-api-native request and response, field by field | Native API reference |
| The OpenRTB bid request Epom sends and the response fields it reads, floors, loss reasons | OpenRTB integration reference |
| Every status glyph, pill, badge and text style in the UI | Statuses & indicators |
| Account tabs, admin sidebar, trees vs grids, bulk actions, shortcuts | UI navigation, grids & trees |
| Upload sizes, field lengths, numeric ranges, login throttling — the value that stops a save | Platform limits |
| Every cookie the ad-serving domains write, its purpose and lifetime | Cookies the ad server sets |
| Folders, files and columns of the raw event export to your own storage | Raw event export files |
Where the reference ends and the guides begin
- A guide’s own reference lives next to the guide, not here. Each long guide has a
… referencesubpage listed under it in the sidebar — for example Limits reference under Set volume limits and budgets, or Campaign reference under Create and edit a campaign. The pages in this section are the ones that span more than one guide. - The REST API has its own section: the REST API overview for authentication, conventions and quotas, the per-area guides with worked calls, and the generated endpoint reference by tag.
- How things work — ad selection, hierarchy and linking, serving state, auctions, the analytics pipelines — is explained in Concepts. A reference page states what a field does; a concept page explains why the ad server behaves as it does.
Reading a reference page
A reference page lists every value, not a sample — if an option, type or metric is not in its table, the product does not offer it. Where a page covers an enum (banner types, placement types, targeting rules, capping), the table carries the internal name and id the REST API accepts next to the label the UI shows, so the same page serves a click in the UI and a call over the API.
