Prepare inventory source inputs

Use this guide when one or more inventory-source inputs or operations must be supplied to Interchange separately. That includes built-in ad-server connections and sources that combine provider APIs, files, or accountable people. It is not required for every Storefront.

Choose the setup path

Your path	What to do
Pass through to an external sales agent	Connect your sales agent. The agent remains responsible for its products, avails, formats, properties, execution, and reporting. Do not prepare this materials pack unless Scope3 will separately operate one of those capabilities.
Use a built-in provider connection	Choose the inventory-source path and provide ad-server access, then use this guide only for inputs the connector does not supply automatically or that still require customer configuration. Built-in ad-server connections include Google Ad Manager, FreeWheel, SpringServe, and AdsWizz; standard provider recipes include CitrusAd.
Combine APIs, files, and human operations	Use this guide to identify each input, its authority, and its operating owner. This is the custom source path, regardless of who operates each capability. Scope3 reviews the map with you before any custom path is activated.
Use a hybrid of both	Apply this guide only to the inventory scopes or operations that the external agent does not fully own. Do not duplicate the pass-through agent’s catalog or capacity.

If every buyer request passes through Interchange unchanged to an external sales agent, stop here. You need the agent connection and authorization, not an avails pack or a source-input worksheet.

Answer five questions first

Start in customer language. Different systems or people may answer each question, and the answers do not need to arrive in one file or at one time.

Question	What to provide or identify	What it establishes
1. Where do avails come from?	The planning API, ad server, forecast, file, or accountable person; stable inventory and capacity-pool IDs; period, unit, gross or net meaning, bookings, source price, cadence, and corrections	What capacity can be offered and when it becomes stale
2. Where do products and their descriptions come from, and how do they map to avails?	An upstream product catalog or the materials Scope3 should use to create one: product/package IDs, buyer-facing names and descriptions, included inventory scopes, availability join keys, rate card, Media Kit, and owner	What buyers discover and which capacity backs each offer
3. Where does CRM or buyer-account context come from?	The CRM system or export, stable account and opportunity IDs, buyer-account mappings, sanitized relationship context, cadence, privacy rules, and owner	Optional buyer-specific context; never inventory or booking authority
4. Where do creative formats come from?	The authoritative format matrix, canonical format mapping, dimensions or duration, asset and approval rules, lead times, and owner	Which products can accept which creative and how compliance is decided
5. Which properties carry the inventory?	The Property Roster or source taxonomy for domains, apps, channels, or other publisher properties; stable selectors, inventory coverage, authorization evidence, and owner	Where the inventory runs and who is authorized to sell it

Record the answers in the source input and authority worksheet. The worksheet records suppliers, joins, authority, cadence, and owners. It does not require the customer to design a software module.

Start with one representative exchange

You do not need to redesign your exports or send every system at once. For the first working session, use existing documentation and sanitized samples where possible:

Bring first	Minimum useful example
Source and system sketch	The ad servers, publisher APIs, files, and operating teams involved, plus the intended pilot inventory scope
Inventory and availability	One representative availability sample with stable inventory IDs, period, unit, gross-or-net meaning, source price, and any booking relationship
Products and properties	Current product or package descriptions, their inventory or availability joins, and the domains, apps, channels, or other properties they cover
Creative requirements	The format matrix, asset and approval rules, lead times, and the team that decides acceptance
One campaign lifecycle	A sanitized example that connects a proposal or order to booking, creative, trafficking, status, delivery, and correction evidence
Merchandising evidence	A current Media Kit or sales deck, rate card, policy or approval rules, and four representative briefs or RFPs
CRM context, if useful now	A field dictionary and a few sanitized account or opportunity rows; omit contact names, email addresses, and other personal data

Tell Scope3 the source system, covered scope, observed or effective period, and owner for each item. Materials may arrive separately. Do not include credentials, manifests, checksums, or production customer PII. Scope3 will return a receipt and version summary, a draft input/authority map, the joined campaign trace, and a list of integration and merchandising gaps. You confirm or correct the map before a custom or manual capability is treated as operational. This first exchange is enough to start a pilot design; it does not by itself enable production transactions.

Prove the operating path

After locating the five core inputs, prove five distinct operating tracks:

Track	What it establishes
Inventory and availability	What can be sold, its stable identity, capacity, source price, and booking constraints
Execution and trafficking	How a reservation becomes an upstream campaign or line item, how creative is approved and trafficked, and how updates, cancellations, failures, and returned IDs are handled
Reporting and reconciliation	How delivery and spend return, join to the booked line, become final, and are corrected
CRM and commercial context (optional)	Account, opportunity, and historical relationship context that can inform buyer-specific merchandising without becoming inventory or booking authority
Merchandising	How eligible source-backed inventory becomes buyer-facing products, prices, positioning, policies, and proposal behavior

The tracks join through stable source, inventory-scope, availability, property, format, product, campaign, account, and reporting identifiers, but their APIs, files, and human confirmations may arrive independently. A source is not fully operational merely because its inventory is visible. Add an AdCP Collection identifier only for canonical content identity such as a series, publication, event series, or rotation. A media kit does not create capacity. An availability feed does not decide the product story.

Send representative or redacted material when files contain buyer, campaign, pricing, or personal data. Do not put credentials, private keys, API tokens, or customer PII in an onboarding file. Enter live credentials only in the dedicated connection flow.

What is production-importable today

Only use a file as a production import when its row shape is documented for an implemented parser.

Material	Classification	What works today
Static avails CSV, XLS, or XLSX	Production-importable for static-avails-feed:v1 (compatibility)	Preview and commit through the modular avails-feed path. This is not the target Inventory Feed schema.
Static avails JSON	Production-importable for static-avails-feed:v1 (compatibility)	Send as JSON text, or upload the document in Murph and use its document reference. This is not the target Inventory Feed schema.
Ad-server wholesale avails and pricing CSV	Production-importable: wholesale-avails-pricing:v1	Download a source-prefilled template, preview, then commit for a Google Ad Manager, FreeWheel, SpringServe, or AdsWizz source.
Source input and authority worksheet	Supporting evidence	Review with Scope3; it is not an import schema.
Product list, rate card, Media Kit, Playbook, and Business Rules	Merchandising evidence	Use the Media Kit as supporting Product Marketing evidence. Apply confirmed structured facts through Discovery Card, Playbook, Business Rules, products/components, and pricing; attaching a file is not ingestion.
Complete campaign, booking, creative, trafficking, status, and reporting examples	Supporting evidence or manual pilot input	Use for contract rehearsal. No generalized importer is implied.
Target Inventory Feed shapes	Target contract / not production input	Do not submit conceptual shapes as production input. Public generated templates will be published only when their production parsers ship.

static-avails-feed:v1 is a production compatibility parser, not the target Inventory Feed schema. Its exact collectionId, collectionName, and collectionDescription fields are legacy grouping/container field names. They have represented generic pools and containers, and their values do not establish AdCP Collection identity. Do not turn a monthly pool, placement, channel, or portfolio into an AdCP Collection to satisfy this parser.

The inventory source example pack contains both parser-backed avails and clearly labeled evidence. Its manifest is test-harness routing metadata maintained by Scope3. Customers do not author manifests or calculate SHA-256 digests. Files, APIs, and human confirmations may arrive independently; Scope3 records receipts and content evidence when each item arrives.

Start with one durable source boundary

Define a source by coherent capacity and booking authority, not by vendor, credential, transport, or filename.

Keep one source when an ad server, publisher API, file, and human workflow describe the same bookable pool and have stable joins.
Use separate sources when inventory has independently allocatable capacity, booking authority, execution, or reporting ledgers.
Do not create a second source merely because a supported provider is connected later.
Never merge existing sources by matching vendor names. First prove shared capacity and booking authority, map identity, compare in shadow, choose the surviving source ID, and retain a rollback path.

Standard provider paths and custom configuration

Built-in ad-server connections for Google Ad Manager, FreeWheel, SpringServe, and AdsWizz are standard supported paths within this model. CitrusAd is exposed through a standard provider recipe. A Scope3-managed sales agent is plumbing behind some of these connections, not a separate provider family. Each connector preconfigures only the inventory, execution, status, and reporting capabilities its published contract supports. A supported feed or accountable person may supply a remaining scope without changing the business-source boundary. Today, ad-server-backed and modular sources still have different setup surfaces. In-place provider conversion and a single generalized source workspace are pilot preview design, not shipped self-service behavior. Ask Scope3 to map supplemental material to the existing source instead of creating a duplicate. Enterprise-assisted custom configuration applies to a customer-specific or not-yet-supported provider/capability configuration, bespoke schema or API pull, custom authority or overlap rule, or negotiated manual service. The assistance applies to that capability and its production activation, not to a new kind of source. Standard supported paths are not Enterprise-gated merely because the source is modular. The current advanced modular-composition surface remains entitlement-gated while this converges. The standard-versus-custom boundary and its capability-specific support rules apply consistently across every source.

Set up inventory and availability

Bring these materials

The Needed to prove column names the first capability that depends on the item. You can start before later materials arrive.

Purpose	Representative material	Needed to prove
Source and system map	Systems, provider accounts, APIs, files, human workflows, and the capacity/booking boundary	Source authority
Inventory identity and authorization	Stable placement, property, and format identifiers; canonical AdCP Collection identifiers only when the publisher declares a series, publication, event series, or rotation; Property Roster and adagents.json ownership	Discovery
Availability and source price	Row-level avails with stable IDs, periods, units, capacity basis, source CPM or floor, and overlap/pool meaning	Discovery and reservation
Upstream bookings, when needed	Order or line-item IDs, source scope, period, quantity/unit, status, and update time	Gross-to-net normalization and reconciliation
Inventory owners and cadence	Owner and backup, trigger or schedule, timezone, expected arrival, grace, stale effect, correction, and escalation	Repeatable inventory operations

Download or copy the source input and authority worksheet. It records provider, scope, stable keys, authority, snapshot/delta/event semantics, cadence, grace, stale consequence, owner, correction, and escalation. It is supporting evidence, not a production import schema.

Stable identity and row grain

Use a stable ID from the system that owns the inventory. Do not use a display name, row number, or file position as identity. One static-avails row represents one availability window within a legacy compatibility grouping. Split rows when the capacity pool, dates, price, currency, property coverage, canonical creative format, or booking ownership changes. Use one event, issue, episode, takeover, or sponsorship row only when it has its own independently controlled capacity. This row grain does not create AdCP Collection identity. Audience scale, market reach, household counts, and co-viewing studies are evidence, not sellable capacity.

Fields required by this starter kit

The production compatibility parser can derive collectionId and availId when they are omitted. This starter kit requires explicit stable IDs so later corrections join predictably. The exact collection* names below remain only for static-avails-feed:v1 parser compatibility.

Field	Requirement
collectionId	Legacy field name. Explicit stable seller-side ID for the parser’s grouping/container. It does not establish AdCP Collection identity.
collectionName	Legacy field name. Seller-facing label for that compatibility grouping/container.
formatOptions	Non-empty URL-free canonical declarations using format_kind and params.
publisherProperties	Non-empty Property selectors for the inventory represented by the compatibility grouping.
availId	Explicit stable ID for the availability line.
name	Seller-facing name for the availability line.
startTime and endTime	ISO dates or date-times for the covered window.
Capacity	impressionsCapacity for net sellable capacity, or gross capacity plus upstream booked capacity.

Optional fields include collectionDescription (legacy field name for the compatibility grouping description), channel, CPM, currency, targeting, sourceMetadata, and source-specific non-secret join keys. Channel is descriptive and never determines creative format.

The current static-avails parser is impression-based with optional CPM. It does not represent click or engagement pricing, whole-flight flat rate, slots, or time-based sponsorships. Keep those native semantics in supporting evidence and treat the missing production contract as a gap.

Net and gross capacity

Use impressionsCapacity only for net sellable capacity available to this source before new local holds or bookings. If the source reports gross capacity, provide one gross field such as avails and one upstream-booked field such as upstreamBookedImpressions. Preview calculates:

net sellable capacity = gross capacity - upstream booked capacity

The parser rejects booked capacity above gross capacity. If you provide net, gross, and booked values together, the explicit net value wins in the current compatibility parser; avoid that ambiguity by using one model per row.

Capacity, cadence, and correction worksheet

For every independently arriving stream, confirm:

Decision	Record
Grain and stable keys	Source, pool, property, placement, availability, campaign, creative, and reporting joins; AdCP Collection only when canonical content identity exists
Authority	Which system or person owns each fact and scope
Delivery semantics	Full snapshot, patch/upsert, delta, event, or human confirmation
Timing	Trigger or cadence, timezone, expected arrival, grace, and freshness limit
Failure effect	Advisory, discovery blocker, reservation blocker, execution blocker, reporting blocker, or pilot blocker
Recovery	Retry, corrected revision, mapping repair, approved exception, owner, backup, and escalation

A late reporting file does not invalidate current inventory identity. An invalid availability revision does not rewrite accepted merchandising facts. Each capability becomes stale or blocked only where its owning stream requires it.

Replacement, patch, and rejection recovery

The current static-avails contract is a patch/upsert keyed by availId:

reusing an ID updates that availability line;
changing the ID creates another line;
omitted rows remain active until they expire or the source is archived;
omission is not deletion or cancellation; and
a rejected update does not retire the last accepted row.

The ad-server wholesale-pricing contract is an atomic full replacement. Follow its separate field and replacement guide. Do not apply one contract’s replacement rules to the other.

Use the Inventory Feed Task for static-avails-feed:v1, or inspect the REST preview response, before correcting a mixed-validity file. Those preview surfaces return rejectedRowCount, rejectedRows, and warnings. The legacy ingest_modular_avails_feed tool does not currently surface those row diagnostics and can commit the accepted subset, so do not use it for rejection recovery or to validate a complete refresh.The canonical Task and REST path also permit an intentional accepted-row patch. They do not enforce zero rejections before commit. When the file is meant to be a complete operational refresh, stop if rejectedRowCount is greater than zero, repair the source file, and preview the whole patch again.

For a rejected static-avails row:

Match rowNumber to the one-based data-row position. CSV data row 1 is file line 2; JSON row 1 is the first item in the avails array.
Repair the named identity, date, number, currency, canonical-format, or property-selector error.
Preview the entire intended patch again.
Confirm row count, stable IDs, periods, price, format/property coverage, and normalized capacity.
Commit only the reviewed preview. Resolve every rejection before treating a complete operational refresh as successful.

static-avails-feed:v1 compatibility templates

These files are maintained as parser tests. They are for the implemented static-avails-feed:v1 compatibility parser only. They are production- importable for that parser, not canonical generalized templates or the target Inventory Feed schema.

Copy static-avails-feed:v1 compatibility CSV

One complete net-capacity row with canonical format and Property declarations; legacy collection* headers remain for parser compatibility.

Copy static-avails-feed:v1 compatibility JSON

One complete gross-minus-booked row for the JSON-text compatibility path.

Copy completed static-avails CSV

Three fictional rows covering net and gross-minus-booked capacity.

Open the completed fictional pack

Parser-backed CTV/display avails plus clearly classified evidence and proposal cases.

Get an ad-server wholesale template

Use the source-prefilled production download endpoint described in this guide.

CSV template: net capacity

collectionId,collectionName,collectionDescription,availId,name,startTime,endTime,impressionsCapacity,channel,cpm,currency,targeting,sourceMetadata,formatOptions,publisherProperties
compat-streaming-group,Legacy group: Streaming video,Static v1 compatibility grouping; not an AdCP Collection,example-streaming-2099-07,Streaming video July,2099-07-01,2099-08-01,4000000,CTV,24.00,USD,"{""market"":""US""}","{""reportingJoinKey"":""report-example-streaming-2099-07""}","[{""format_option_id"":""example_ctv_vast"",""format_kind"":""video_vast"",""params"":{""duration_ms_exact"":30000}}]","[{""selection_type"":""all"",""publisher_domain"":""example-publisher.synthetic.invalid""}]"

JSON template: gross minus booked

{
  "avails": [
    {
      "collectionId": "compat-broadcast-group",
      "collectionName": "Legacy group: Broadcast video",
      "collectionDescription": "Static v1 compatibility grouping; not an AdCP Collection",
      "availId": "example-broadcast-2099-07",
      "name": "Broadcast video July",
      "startTime": "2099-07-01",
      "endTime": "2099-08-01",
      "avails": 1000000,
      "upstreamBookedImpressions": 200000,
      "channel": "broadcast",
      "cpm": 18,
      "currency": "USD",
      "targeting": {
        "market": "US"
      },
      "sourceMetadata": {
        "reportingJoinKey": "report-example-broadcast-2099-07"
      },
      "formatOptions": [
        {
          "format_option_id": "example_broadcast_vast",
          "format_kind": "video_vast",
          "params": { "duration_ms_exact": 30000 }
        }
      ],
      "publisherProperties": [
        {
          "selection_type": "all",
          "publisher_domain": "example-publisher.synthetic.invalid"
        }
      ]
    }
  ]
}

Upload CSV, XLS, or XLSX through the static-avails file-upload path. Send JSON through jsonText; the REST multipart endpoint does not accept JSON files. Murph can instead use an uploaded JSON document reference. TSV is accepted only as pasted CSV text, not as a multipart file.

Set up execution and trafficking

Inventory visibility does not establish an execution path. For each intended pilot scope, identify the system or accountable person that owns each operation and provide representative evidence for:

Operation	Materials and proof needed
Reserve, book, release	Request and response or named manual work item; quantity and unit; idempotency or duplicate handling; returned reservation, order, or line-item IDs
Create and approve a campaign	Advertiser alias, dates, budget, product and inventory scope, targeting, price, approvals, and returned upstream IDs
Approve and traffic creative	Exact format and asset rules, lead times, approval and rejection examples, creative references, handoff evidence, and owner
Observe status and failures	State vocabulary, success and failure evidence, observed time, retry behavior, customer-visible pending state, and escalation
Update, cancel, and release	One representative update and cancellation, released capacity, version or correction behavior, and final returned state

Classify each operation as connected automation, named human or secure-file pilot step, or gap. A manual step counts for a pilot only when it has an owner, response expectation, durable evidence, failure handling, and escalation. One successful handoff does not prove update, cancellation, retry, or release. This starter kit does not claim a generalized execution or trafficking importer. Use supplied materials to prove the exact supported operation or to rehearse a manual pilot; do not treat them as production API requests.

Set up reporting and reconciliation

Provide a representative delivery and spend report that can join to the exact booked line. Before calling the source reporting-ready, establish:

stable source, media-buy or package, upstream order, and line-item joins;
report period, delivered quantity and unit, spend and currency;
whether each value is observed, estimated, or modeled;
preliminary, final, and corrected report identity and finality rules;
cadence or trigger, timezone, expected arrival, grace window, and the effect of stale or missing data; and
correction, quarantine, replay, owner, backup, and escalation behavior.

The reporting example in this kit is supporting evidence. It becomes a production reporting path only when a documented importer or an approved, operated manual workflow proves the exact source scope and cadence. A customer commitment such as daily, weekly, or quarterly reporting must be recorded with its delivery window and enforced stale-data consequence.

Add CRM and commercial context (optional)

CRM context is an optional input to buyer-specific merchandising and operating decisions. Useful evidence includes a CRM field dictionary, five to ten sanitized account or opportunity rows, buyer-account mappings, and representative proposal outcomes. Useful fields include stable CRM account and opportunity IDs, an account alias and type, opportunity stage, referenced product or package, expected flight, amount and currency, outcome or loss reason, seller-owner role, last activity time, and source update time. Remove contact names, email addresses, and other personal data. CRM material is supporting evidence, not inventory, availability, booking authority, a canonical buyer account, or a production import schema. A missing CRM feed does not block inventory, execution, or reporting setup unless a specific approved workflow declares that dependency. See the sanitized CRM example.

Make it merchandisable

Once inventory identity and readiness are explicit, route buyer-facing decisions to their canonical owners:

Decision	Owning surface	Proof
Product/package definition	Inventory products/components	Every offer points to eligible source identity and grounded evidence
Storefront positioning	Discovery Card; Media Kit is supporting Product Marketing evidence	Buyer-facing positioning uses confirmed facts without treating the Media Kit as an owning surface
Structured selling price and currency	Pricing owner	Deterministic price respects source floors and effective periods
Selection, packaging, event/seasonality, and explanation	Playbook	Repeated brief tests select and explain the expected products
Advertiser and creative acceptance	Business Rules	Fit, rejection, and review cases match policy without exposing private rules
Buyer-specific treatment	Buyer discounts and instructions	Terms apply only to the intended buyer and remain auditable

Prove source-scoped proposal behavior

Use the fictional briefs in the sample pack to run:

an obvious fit with the expected source-scoped product;
a correct no-fit or policy rejection;
a human-review case;
a stale or conflicting-source case;
a source-isolation case that must not return another source’s product; and
a pricing or format edge case that must ask for clarification or decline instead of inventing support.

Know what proposal proof does not establish

A source-scoped proposal test is a pilot preview of discovery behavior. It does not contact a buyer, create a media buy, confirm upstream booking, traffic a campaign, import delivery, or prove production readiness.

Rehearse one complete campaign

Open the sanitized complete-campaign example. It joins advertiser, campaign/order/line item, dates, budget, source product, targeting, quantity/unit, price, creative, approval, status, delivery, reporting, and returned IDs. It is supporting evidence and a manual pilot walkthrough, not a production API request or import schema. Classify every stage in the rehearsal:

Stage	Valid verdict
Discovery and proposal	Available now, pilot preview, or blocked
Reservation and transaction	Production path, approved manual path, or blocked
Creative and trafficking	Production path, named human work with durable evidence, or blocked
Status, update, and cancellation	Production path, named human work with durable evidence, or blocked
Reporting and reconciliation	Production import, approved manual evidence, or blocked

Do not use a successful feed preview or compelling proposal as evidence that a booking, campaign, trafficking, reporting, or conversion workflow exists.

Readiness decisions

Readiness is decided per track and per source scope. One green track does not make the others green.

Inventory-ready

Stable inventory identity, authorization, property and format coverage, capacity semantics, source-price constraints, booking overlap, cadence, correction behavior, and owners are proven for the intended scope. This means the source can make truthful availability decisions. It does not prove that a campaign can be executed or reported.

Merchandising-ready

Stable inventory identity and selling-rights evidence appropriate to the source, exact formats, current capacity/source constraints, product definition, structured selling price, positioning, Playbook guidance, and Business Rules support fit, rejection, review, edge, and source-isolation tests. Where publisher authorization applies, require current positive authorization evidence. For a connected platform account where it does not apply, use the connection-based selling rights rather than inventing an adagents.json requirement. This means buyers can be shown a truthful pilot preview. It does not mean they can transact.

Execution-ready

The exact offer has a proven reservation and booking path, creative and trafficking ownership, returned upstream IDs, status and failure handling, update, cancellation, retry, and release behavior. This decision is independent of whether reporting is ready.

Transaction-ready

The exact offer is both inventory-ready and execution-ready, with no hard readiness blocker. A named human may satisfy a pilot stage only when the work item, response expectation, evidence, and escalation are operational.

Reporting-ready

Delivery and spend join to the booked line with stable source IDs, an agreed cadence and finality rule, correction behavior, and an owned quarantine path. The general reporting example in this kit is evidence only until a production importer or approved manual workflow proves this stage.

CRM context available (optional)

Sanitized account and opportunity context has stable joins, declared authority, privacy handling, cadence, and an owner for the workflow that consumes it. This is not a prerequisite for inventory-, execution-, transaction-, or reporting-readiness unless the approved workflow explicitly makes it one.

Pilot preview

A pilot preview may classify materials, run current parsers, inspect projected products, and test source-scoped proposal behavior. It must display unsupported transaction, creative, trafficking, status, reporting, or conversion stages as manual or gaps. It is never a production-launch verdict.

Operationally self-sufficient

The publisher team can refresh each stream, interpret diagnostics, correct revisions, operate manual queues, release capacity, reconcile reports, and escalate exceptions through named owners and backups. This is an operating milestone, not one API status.

Choose an inventory source

Compare current connection and pilot paths.

Modular source lifecycle

Use the current static-avails preview, patch, reservation, and work-item flow.

Discovery Card, Playbook, and Business Rules

Put confirmed structured facts in their authoritative Pages and use the Media Kit as supporting evidence.

Property Roster

Reconcile Properties, canonical AdCP Collections when present, formats, and authorization.

​Choose the setup path

​Answer five questions first

​Start with one representative exchange

​Prove the operating path

​What is production-importable today

​Start with one durable source boundary

​Standard provider paths and custom configuration

​Set up inventory and availability

​Bring these materials

​Stable identity and row grain

​Fields required by this starter kit

​Net and gross capacity

​Capacity, cadence, and correction worksheet

​Replacement, patch, and rejection recovery

​static-avails-feed:v1 compatibility templates

Copy static-avails-feed:v1 compatibility CSV

Copy static-avails-feed:v1 compatibility JSON

Copy completed static-avails CSV

Open the completed fictional pack

Get an ad-server wholesale template

​CSV template: net capacity

​JSON template: gross minus booked

​Set up execution and trafficking

​Set up reporting and reconciliation

​Add CRM and commercial context (optional)

​Make it merchandisable

​Prove source-scoped proposal behavior

​Know what proposal proof does not establish

​Rehearse one complete campaign

​Readiness decisions

​Inventory-ready

​Merchandising-ready

​Execution-ready

​Transaction-ready

​Reporting-ready

​CRM context available (optional)

​Pilot preview

​Operationally self-sufficient

​Related guides

Choose an inventory source

Modular source lifecycle

Discovery Card, Playbook, and Business Rules

Property Roster

Choose the setup path

Answer five questions first

Start with one representative exchange

Prove the operating path

What is production-importable today

Start with one durable source boundary

Standard provider paths and custom configuration

Set up inventory and availability

Bring these materials

Stable identity and row grain

Fields required by this starter kit

Net and gross capacity

Capacity, cadence, and correction worksheet

Replacement, patch, and rejection recovery

static-avails-feed:v1 compatibility templates

CSV template: net capacity

JSON template: gross minus booked

Set up execution and trafficking

Set up reporting and reconciliation

Add CRM and commercial context (optional)

Make it merchandisable

Prove source-scoped proposal behavior

Know what proposal proof does not establish

Rehearse one complete campaign

Readiness decisions

Inventory-ready

Merchandising-ready

Execution-ready

Transaction-ready

Reporting-ready

CRM context available (optional)

Pilot preview

Operationally self-sufficient

Related guides