Prepare inventory source inputs

You are inside Step 2 of storefront onboarding, connect inventory sources. Use this page when a connector cannot supply everything on its own and you must provide some inputs yourself: avails, products, properties, creative formats, execution, or reporting. Many storefronts never need this page. If every buyer request passes straight through to an external sales agent, you need the agent connection and nothing here.

What this page walks you through

Steps 1–4 scope the work. Steps 5, 9, and 10 line up with the three sections of your source’s live readiness checklist — Set up inventory, Make it merchandisable, and Prove it — so this page and the checklist name the same things. Steps 6 and 7 are not checklist rows at all: they are reported as lifecycle stages. Step 8 has no status of its own.

#	Step	Reported as	What it settles	Requirement
1	Confirm you need this page	—	Whether your path needs separately supplied inputs	Required
2	Draw one source boundary	—	What counts as a single inventory source	Required
3	Answer five questions	—	Where each input comes from and who owns it	Required
4	Send one representative sample	—	A shared, corrected map of your setup	Required
5	Set up inventory	Set up inventory checklist rows	What can be sold, its identity, capacity, and price floors	Required
6	Set up execution and trafficking	Lifecycle stages	How a reservation becomes a booked, trafficked campaign	Required to transact
7	Set up reporting and reconciliation	Lifecycle stages	How delivery and spend come back and become final	Required to reconcile
8	Add CRM context	Nothing — supporting evidence	Buyer-specific merchandising context	Recommended
9	Make it merchandisable	Make it merchandisable checklist rows	What buyers see, how it is priced and explained	Required for discovery
10	Prove it	Prove it checklist row	That the whole path holds end to end	Required

Order and dependencies. Do steps 1–4 first and in order. Steps 5–8 are then independent tracks: each is proven and signed off on its own, and their materials may arrive at different times from different people. Two dependencies are hard — step 5 before step 9, and both before a proposal means anything. Discovery needs 5 and 9; transacting also needs 6. One green track never makes another green. Steps 5–7 each correspond to a module your source attaches: INVENTORY_FEED (step 5), BOOKING_LEDGER and TRAFFICKING (step 6), and STATUS_SYNC and REPORTING_IMPORT (steps 6–7). This page is what you prepare before any of that can report ready — see how to read your status for where the real state lives once the source exists.

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

1. Confirm you need this page

Find your path. The first two mostly bypass this page; the last two need it.

Your path	What to do
Pass through to an external sales agent	Connect your sales agent and stop. The agent stays responsible for its products, avails, formats, properties, execution, and reporting.
Use a built-in provider connection	Choose the source path and provide ad-server access. Built-in connections cover Google Ad Manager, FreeWheel, SpringServe, and AdsWizz; CitrusAd runs as a standard provider recipe. Come back here only for inputs the connector does not supply.
Combine APIs, files, and human operations	Use every step below to identify each input, its authority, and its operating owner. Scope3 reviews the map with you before a custom path is activated.
Hybrid	Apply these steps only to the scopes the external agent does not fully own. Do not duplicate its 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.

2. Draw one source boundary

Everything else on this page is scoped to a source, so define the source first. A source boundary is the line around one bookable pool: the inventory whose capacity and booking authority are controlled together. It is not a vendor, a credential, a transport, or a filename.

One source when an ad server, publisher API, file, and human workflow all describe the same bookable pool and share stable joins.
Separate sources when inventory has independently allocatable capacity, booking authority, execution, or reporting ledgers.
Not a new source merely because a supported provider is connected later.
Never merge sources by matching vendor names. First prove shared capacity and booking authority, map identity, compare in shadow, choose the surviving source ID, and keep a rollback path.

Standard paths and custom configuration

Built-in ad-server connections for Google Ad Manager, FreeWheel, SpringServe, and AdsWizz are standard supported paths within this model, and standard provider recipes include CitrusAd. A Scope3-managed sales agent is plumbing behind some of these connections, not a separate provider family. Each connector preconfigures only the capabilities its published contract supports, and a feed or an accountable person can supply a remaining scope without changing the source boundary. Ad-server-backed and modular sources still have separate setup surfaces today, so ask Scope3 to map supplemental material onto the existing source rather than creating a duplicate. Enterprise-assisted custom configuration applies to a customer-specific or not-yet-supported provider/capability configuration, a bespoke schema or API pull, a custom authority or overlap rule, or a negotiated manual service. It applies to that capability and its activation, not to a new kind of source. Standard supported paths are not Enterprise-gated merely because the source is modular. The advanced modular-composition surface is included with Premium and Enterprise through the Merchandising profile, and in-place provider conversion and a single generalized source workspace are pilot preview design, not shipped self-service behavior.

3. Answer five questions

These five answers tell us where each input comes from and who owns it. Answer in your own language — different systems or people may answer each one, at different times.

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, corrections	What capacity can be offered, and when it goes stale
2. Where do products and their descriptions come from, and how do they map to avails?	An upstream catalog, or the materials Scope3 should build one from: product/package IDs, buyer-facing names and descriptions, included inventory scopes, availability join keys, rate card, Media Kit, 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, 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, owner	Which products accept which creative, and how compliance is decided
5. Which properties carry the inventory?	The Property Roster or source taxonomy for domains, apps, and channels; stable selectors, inventory coverage, authorization evidence, owner	Where the inventory runs, and who is authorized to sell it

Record the answers in the source input and authority worksheet. It captures suppliers, joins, authority, cadence, and owners. You are not being asked to design a software module.

4. Send one representative sample

One working session, one pilot scope, existing documentation and sanitized samples. Do not redesign your exports or send every system at once.

Bring first	Minimum useful example
Source and system sketch	The ad servers, APIs, files, and operating teams involved, plus the intended pilot scope
Inventory and availability	One 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 availability joins, and the properties they cover
Creative requirements	Format matrix, asset and approval rules, lead times, and the team that decides acceptance
One campaign lifecycle	A sanitized example joining a proposal or order to booking, creative, trafficking, status, delivery, and corrections
Merchandising evidence	Current Media Kit or sales deck, rate card, policy rules, and four representative briefs or RFPs
CRM context, if useful now	A field dictionary and a few sanitized account rows, with no contact names or email addresses

For each item, name the source system, covered scope, effective period, and owner. Items may arrive separately. Do not include credentials, manifests, checksums, or production PII. What you get back: 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 that map before any custom or manual capability counts as operational. This is enough to start a pilot design; it does not by itself enable production transactions.

What counts as a production import today

A file is a production import only when its row shape is documented for an implemented parser. Everything else is evidence Scope3 reviews with you.

Material	Classification	What works today
Static avails CSV, XLS, or XLSX	Production import — `static-avails-feed:v1` (compatibility)	Preview and commit through the modular avails-feed path. Not the target Inventory Feed schema.
Static avails JSON	Production import — `static-avails-feed:v1` (compatibility)	Send as JSON text, or upload the document in Murph and use its document reference. Not the target Inventory Feed schema.
Ad-server wholesale avails and pricing CSV	Production import — `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	Reviewed with Scope3. Not an import schema.
Product list, rate card, Media Kit, Playbook, AI Business Rules	Merchandising evidence	Confirmed facts are applied through Listing, Playbook, AI 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	Used for contract rehearsal. No importer is implied.
Target Inventory Feed shapes	Target contract, not production input	Do not submit conceptual shapes as production input. Templates are published when their parsers ship.

static-avails-feed:v1 is a production compatibility parser, not the target Inventory Feed schema. Its collectionId, collectionName, and collectionDescription fields are legacy grouping/container 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 holds 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.

Download the synthetic example pack

Start from one ZIP containing directly previewable CTV and display avails, merchandising inputs, lifecycle evidence, proposal tests, and a deliberately invalid feed for rehearsing diagnostics.

5. Set up inventory

Establishes what can be sold: its stable identity, capacity, source price, and booking constraints. Nothing downstream is provable without it.

Bring these materials

This step feeds four checklist rows. Three are always required. Resolve Property Roster identities and formats is REQUIRED only when catalog declaration validation applies to the source contract; the live checklist reports NOT_APPLICABLE otherwise, and no Property Roster or adagents.json work is required for that row. You can start before the later materials arrive.

Checklist row it satisfies	Requirement	Bring this
Configure the source and inventory-feed module	Required	Systems, provider accounts, APIs, files, human workflows, and the capacity/booking boundary
Preview and commit inventory	Required	Row-level avails with stable IDs, periods, units, capacity basis, source CPM or floor, and overlap/pool meaning
Resolve Property Roster identities and formats	Required when catalog declaration validation applies; otherwise not applicable	Stable placement, property, and format identifiers; Property Roster and `adagents.json` ownership; canonical AdCP Collection identifiers only when the publisher declares a series, publication, event series, or rotation
Keep source inventory current	Required	Owner and backup, trigger or schedule, timezone, expected arrival, grace, stale effect, correction, escalation
(gross-to-net and reconciliation, when needed)	Conditional supporting material	Upstream order or line-item IDs, source scope, period, quantity/unit, status, update time

The source input and authority worksheet records provider, scope, stable keys, authority, snapshot/delta/event semantics, cadence, grace, stale consequence, owner, correction, and escalation. It is supporting evidence, not an import schema.

Stable identity and row grain

Use a stable ID from the system that owns the inventory. Never use a display name, row number, or file position as identity. One static-avails row is one availability window inside a legacy compatibility grouping. Split rows when the capacity pool, dates, price, currency, property coverage, canonical creative format, or booking ownership changes. Give an event, issue, episode, takeover, or sponsorship its own row only when it has independently controlled capacity. 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 them explicitly so later corrections join predictably. The collection* names exist only for static-avails-feed:v1 compatibility.

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

Optional: collectionDescription (legacy name), channel, cpm, currency, targeting, sourceMetadata, and non-secret source join keys. Channel is descriptive and never determines creative format.

The current static-avails parser is impression-based with optional CPM. It cannot 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 your source reports gross, send one gross field such as avails and one upstream-booked field such as upstreamBookedImpressions. Preview calculates:

net sellable capacity = gross capacity - upstream booked capacity

Booked above gross is rejected. If net, gross, and booked all appear, the explicit net value wins — avoid the ambiguity by using one model per row.

Cadence and corrections

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 where 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, freshness limit
Failure effect	Advisory, or a discovery / reservation / execution / reporting / pilot blocker
Recovery	Retry, corrected revision, mapping repair, approved exception, owner, backup, escalation

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

Replacement, patch, and rejection recovery

The static-avails contract is a patch/upsert keyed by availId: reusing an ID updates that line, changing it creates another, and 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. Never 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 surfaces return rejectedRowCount, rejectedRows, and warnings. The legacy ingest_modular_avails_feed tool does not surface row diagnostics and can commit the accepted subset, so do not use it for rejection recovery or to validate a complete refresh.The Task and REST paths also permit an intentional accepted-row patch and do not enforce zero rejections before commit. When the file is meant to be a complete operational refresh, stop if rejectedRowCount is above zero, repair the file, and preview the whole patch again.

To fix a rejected 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 and 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 for the implemented static-avails-feed:v1 compatibility parser. They are production-importable for that parser only, not canonical generalized templates or the target Inventory Feed schema.

Copy the compatibility CSV

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

Copy the compatibility JSON

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

Copy completed static-avails CSV

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

Get an ad-server wholesale template

Use the source-prefilled production download endpoint.

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, never as a multipart file.

6. Set up execution and trafficking

Establishes how a reservation becomes an upstream campaign or line item. Inventory being visible proves none of this. For each intended pilot scope, name the system or person that owns each operation and provide evidence for it:

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, returned upstream IDs
Approve and traffic creative	Exact format and asset rules, lead times, approval and rejection examples, creative references, handoff evidence, owner
Observe status and failures	State vocabulary, success and failure evidence, observed time, retry behavior, customer-visible pending state, escalation
Update, cancel, release	One representative update and cancellation, released capacity, version or correction behavior, final returned state

Classify how each operation is fulfilled, using the modes your source reports once connected — AUTOMATED (a module runs it), HITL (a named human or secure-file step completes it), or UNSUPPORTED (a gap). One operation can carry more than one mode, such as automation with a named human fallback. The mode is not a readiness verdict: your source reports stage readiness separately, and an AUTOMATED stage can still be blocked. A HITL step counts for a pilot only with 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 these materials to prove a supported operation or rehearse a manual pilot — never as production API requests.

7. Set up reporting and reconciliation

Establishes how delivery and spend come back, join to the booked line, and become final. Provide a representative delivery and spend report that joins to the exact booked line, plus:

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;
correction, quarantine, replay, owner, backup, and escalation behavior.

The reporting example in this kit is 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 its enforced stale-data consequence.

8. Add CRM and commercial context

An optional input to buyer-specific merchandising. Skip it unless an approved workflow depends on it — it never blocks inventory, execution, or reporting setup. Useful evidence: a CRM field dictionary, five to ten sanitized account or opportunity rows, buyer-account mappings, and representative proposal outcomes. Useful fields: stable CRM account and opportunity IDs, 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, 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. See the sanitized CRM example.

9. Make it merchandisable

Turns eligible source-backed inventory into what buyers actually see: products, prices, positioning, policies, and proposal behavior. Each decision has one canonical owning surface — never a file you attached. These are the rows your source’s Make it merchandisable checklist reports, with the requirement each one carries:

Checklist row	Owning surface	Requirement	Proof
Publish buyer-visible products	Product catalog	Required	Every offer points to eligible source identity and grounded evidence
Attach source pricing	Pricing	Required	Every active row has CPM and currency; price respects source floors and effective periods
Map inventory components	Inventory components	Recommended	Components resolve to ready source identity
Apply properties to decisioning inputs	Decisioning inputs	Recommended	Properties are mapped to the inputs that decide selection
Set selling behavior	Playbook	Recommended	Repeated brief tests select and explain the expected products
Set acceptance policy	AI Business Rules	Recommended	Fit, rejection, and review cases match policy without exposing private rules

Two more surfaces sit alongside the checklist:

Decision	Owning surface	Proof
Storefront positioning	Listing (the Media Kit is supporting evidence)	Positioning uses confirmed facts, and the Media Kit is never treated as an owning surface
Buyer-specific treatment	Buyer discounts and buyer instructions	Terms apply only to the intended buyer and stay auditable

10. Prove it

Two proofs before go-live: the source-scoped discovery proof your checklist requires, then one full campaign rehearsal.

Run source-scoped discovery proof

Required. Run six cases from the briefs in the example pack, including a source-isolation case:

an obvious fit returning 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;
a pricing or format edge case that must ask for clarification or decline rather than invent support.

Know what proposal proof does not establish

A passing proof 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

Walk one campaign through every stage and record an honest verdict for each. Open the sanitized complete-campaign example, which joins advertiser, campaign/order/line item, dates, budget, source product, targeting, quantity/unit, price, creative, approval, status, delivery, reporting, and returned IDs. It is a manual pilot walkthrough, not a production API request or import schema. Record two things per stage, because your source reports them separately:

Which mode or modes fulfil it — modes is a list, so a stage can report more than one, such as automation with a named human fallback. It is empty when nothing declared how the stage operates.
Its readiness status — exactly one of READY, BLOCKED, MISSING_SETUP, RUNTIME_INPUTS_REQUIRED, HITL_PENDING, UNSUPPORTED, or NOT_DECLARED.

Mode and status are independent: an AUTOMATED stage can still be BLOCKED, so a rehearsal that records only the mode can mark an unready campaign path as proven. Two statuses are easy to misread. UNSUPPORTED means every attached module declared what it runs and none of them runs this stage — a real gap you can close by attaching a module that does. NOT_DECLARED means a module that could run the stage is attached but we could not read what it does, so whether it runs is unknown rather than absent; no configuration of yours produces or clears it, so tell Murph instead of treating it as a setup task.

What you rehearse	Stages it covers
Discovery and proposal	`GET_PRODUCTS`
Reservation and booking	`RESERVE_AVAILS`, `FINALIZE_BOOKING`
Creative and trafficking	`SYNC_CREATIVES`, `TRAFFIC_CAMPAIGN`
Status, update, cancellation	`SYNC_STATUS`, `UPDATE_CAMPAIGN`, `RELEASE_BOOKING`
Reporting and reconciliation	`IMPORT_REPORTING`, `RECONCILE_DELIVERY`

Never treat a successful feed preview or a compelling proposal as evidence that a booking, campaign, trafficking, reporting, or conversion workflow exists.

How to read your status

Nothing on this page is a status. Once the source exists, three surfaces report the real state, and each answers a different question:

Your question	Where to read it	Ready looks like
Can this source make truthful availability decisions?	Set up inventory section of the source’s readiness checklist	Every `REQUIRED` row `READY`, with `freshness: FRESH`
Can buyers be shown a truthful product?	Make it merchandisable section	Publish buyer-visible products and Attach source pricing `READY`
Does discovery behave correctly for this source alone?	Prove it section	Run source-scoped discovery proof `READY`
Can a booking be reserved, trafficked, and updated?	The source’s lifecycle stages	`RESERVE_AVAILS`, `FINALIZE_BOOKING`, `RELEASE_BOOKING`, `SYNC_CREATIVES`, `TRAFFIC_CAMPAIGN`, `UPDATE_CAMPAIGN`, and `SYNC_STATUS` all `READY`
Does delivery and spend come back?	The source’s lifecycle stages	`IMPORT_REPORTING` and `RECONCILE_DELIVERY` `READY`
Can the storefront transact at all?	Storefront readiness	`canTransact: true` and `effectiveStatus: live`, with no `hard` requirement outstanding

Read each answer on its own. A READY checklist section does not make a lifecycle stage ready, and neither one makes the storefront live. A stage reported as HITL is fulfilled by a named human rather than automation. It counts only when the work item, response expectation, durable evidence, failure handling, and escalation are operational; UNSUPPORTED is a gap. Two things this page prepares have no status of their own: CRM context is recommended supporting evidence, and whether your team can operate the source unaided — refreshing each stream, reading diagnostics, correcting revisions, working manual queues, releasing capacity, reconciling reports, and escalating through named owners — is a conversation with Scope3, not a field.

Where publisher authorization applies, require current positive authorization evidence before inventory is merchandisable. For a connected platform account where it does not apply, use the connection-based selling rights rather than inventing an adagents.json requirement.

Choose an inventory source

Compare current connection and pilot paths.

Modular source lifecycle

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

Listing, Playbook, and AI Business Rules

Put confirmed facts in their authoritative Pages and keep the Media Kit as evidence.

Property Roster

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

Start here

Buy media

Sell media

Help and updates

Prepare inventory source inputs

What this page walks you through

1. Confirm you need this page

2. Draw one source boundary

Standard paths and custom configuration

3. Answer five questions

4. Send one representative sample

What counts as a production import today

Download the synthetic example pack

5. Set up inventory

Bring these materials

Stable identity and row grain

Fields required by this starter kit

Net and gross capacity

Cadence and corrections

Replacement, patch, and rejection recovery

`static-avails-feed:v1` compatibility templates

Copy the compatibility CSV

Copy the compatibility JSON

Copy completed static-avails CSV

Get an ad-server wholesale template

CSV template: net capacity

JSON template: gross minus booked

6. Set up execution and trafficking

7. Set up reporting and reconciliation

8. Add CRM and commercial context

9. Make it merchandisable

10. Prove it

Run source-scoped discovery proof

Know what proposal proof does not establish

Rehearse one complete campaign

How to read your status

Choose an inventory source

Modular source lifecycle

Listing, Playbook, and AI Business Rules

Property Roster

​What this page walks you through

​1. Confirm you need this page

​2. Draw one source boundary

​Standard paths and custom configuration

​3. Answer five questions

​4. Send one representative sample

​What counts as a production import today

Download the synthetic example pack

​5. Set up inventory

​Bring these materials

​Stable identity and row grain

​Fields required by this starter kit

​Net and gross capacity

​Cadence and corrections

​Replacement, patch, and rejection recovery

​static-avails-feed:v1 compatibility templates

Copy the compatibility CSV

Copy the compatibility JSON

Copy completed static-avails CSV

Get an ad-server wholesale template

​CSV template: net capacity

​JSON template: gross minus booked

​6. Set up execution and trafficking

​7. Set up reporting and reconciliation

​8. Add CRM and commercial context

​9. Make it merchandisable

​10. Prove it

​Run source-scoped discovery proof

​Know what proposal proof does not establish

​Rehearse one complete campaign

​How to read your status

​Related guides

Choose an inventory source

Modular source lifecycle

Listing, Playbook, and AI Business Rules

Property Roster

What this page walks you through

1. Confirm you need this page

2. Draw one source boundary

Standard paths and custom configuration

3. Answer five questions

4. Send one representative sample

What counts as a production import today

5. Set up inventory

Bring these materials

Stable identity and row grain

Fields required by this starter kit

Net and gross capacity

Cadence and corrections

Replacement, patch, and rejection recovery

`static-avails-feed:v1` compatibility templates

CSV template: net capacity

JSON template: gross minus booked

6. Set up execution and trafficking

7. Set up reporting and reconciliation

8. Add CRM and commercial context

9. Make it merchandisable

10. Prove it

Run source-scoped discovery proof

Know what proposal proof does not establish

Rehearse one complete campaign

How to read your status

Related guides