Listing, Playbook, and AI Business Rules

​

One fact, one owner

​

Reading singleton nouns and the storefront projection

{ "kind": "seller", "include": ["listing"] }

{ "kind": "business_rules" }

{ "kind": "playbook", "include": ["versions"] }

{ "kind": "playbook", "version": 2 }

​

Listing — what buyers see

{
  "description": "Regional lifestyle and news network reaching auto intenders across France.",
  "channels": ["display", "ctv"],
  "countries": ["FR"]
}

{ "page": "discovery_card" }

​

Listing — four steps and destinations

1. Identity. Name and logo resolved from the verified brand domain and brand.json; link or correct that identity instead of forking it on the listing.
2. What you do. Description, buyer-visible channels, accepted countries, and the selected Advertising Policies disclosure. This is shared input for every destination below, not a ChatGPT-only listing.
3. Listed on Apostra marketplace. A switch included with every account. Live means buyer agents can find the storefront on Apostra; turning it off unlists the storefront everywhere, with a confirmation.
4. Public distribution. The gate for every app destination. Add the Distribution package (the paid upgrade — see what it costs before committing), then point your domain at Apostra with one CNAME at your registrar; Apostra checks it for you. Once the domain verifies, choose Make it public to take Public distribution live — verifying alone does not publish — and verifying requires the storefront to already have a published Apostra listing (step 3). Apostra first-party storefront is attached to platform-managed hosting automatically and never shows this step.

• Brand domain. Save the domain this storefront operates as. See Domains for what the brand domain does and how alias verification works. Saving is explicit — there is no autosave.
• Verification status. Instead of an unexplained “Verify” button (that action is Apostra-admin only), the page shows the plain-language reason your domain is pending — for example, that your account has no registered domain yet, or that the registered domain still needs member-email or Apostra approval. This is explanatory text on the page itself, not a link; see Domains for the full rules. Once verified, buyers can trust the identity resolved above.
• Brand identity. The top card starts with the operator domain and shows where identity came from: a website-hosted brand.json, an AAO-managed identity, a community fallback, or no file. A website-hosted file remains read-only here. When no file exists, the AAO builder offers self-hosting or managed hosting after domain verification. This is optional; channel assets can still be uploaded directly.
• ChatGPT app destination. Once Public distribution is live, Request access requests reviewer access; after activation, the storefront receives its no-spend reviewer advertiser and Download your OpenAI package appears. Prove domain ownership to OpenAI from the same tab by pasting the token OpenAI gives you. There is no dedicated ChatGPT hostname, app-store category selector, or submission-review checkbox on this platform — Apostra sets the directory category to Business for new registrations (an existing registration keeps its saved category) and shows the value before you download, and OpenAI’s review happens in OpenAI’s own portal. See Create a white-label ChatGPT app for the full walkthrough, including what happens on OpenAI’s side after you submit. Storefronts with icons uploaded before automatic generation was introduced continue serving those existing icons during migration. New registrations use resolved brand identity automatically until the owner uploads both channel-specific icons. An existing app still served from its own legacy per-app hostname keeps its ChatGPT destination (and Claude’s, since the same public endpoint already exists there) reachable before Public distribution goes live: an existing reviewer grant, your token, and the package stay available and maintainable without waiting on step four (requesting a new reviewer grant still needs Public distribution and the Distribution package) — move to your public listing domain there when you’re ready; the app keeps working until then.
• Claude destination. Once Public distribution is live, the Claude tab confirms that the storefront’s public MCP endpoint is ready and links to Anthropic’s Connector Directory submission walkthrough. OAuth and the storefront’s server-side permissions still decide which accounts and tools each person can access. Anthropic’s policy checks, directory review, and approval remain separate from endpoint readiness. In Anthropic’s Authentication step, select OAuth 2.0 + Dynamic Client Registration; the public MCP endpoint publishes the rest of the OAuth metadata. In Test & launch, choose Open reviewer login in Apostra and paste that email and password into the protected test-setup instructions with these steps: connect the listed MCP URL, complete OAuth with the supplied login, and run get_status to confirm the no-spend System advertiser before testing the remaining tools. The same login can be reopened for OpenAI, Anthropic, and Microsoft while its grant is active. It is not included in a download, repository, support ticket, or model-visible tool result; revoke it from either destination when directory review ends.

​

Rate cards — how you price

​

playbook — how you sell

{
  "content": "## Posture\nLead with premium CTV before offering display discounts. Hold value on flagship inventory during Q4.\n\n## Packaging\nBundle CTV pre-roll with display when a brief mentions video.",
  "notes": "Initial playbook, drafted from the Q4 sales deck.",
  "pricing": {
    "currency": "USD",
    "facts": [
      {
        "id": "ctv-flagship",
        "label": "CTV flagship pre-roll",
        "appliesWhen": "Buyer requests CTV pre-roll on flagship shows",
        "pricingModel": "cpm",
        "targetPrice": 42,
        "floorPrice": 32,
        "strength": "hard_floor",
        "provenance": "2026 rate card, page 4"
      }
    ]
  }
}

{
  "playbook": {
    "active": {
      "version": 3,
      "content": "## Posture\nLead with premium CTV before offering display discounts. Hold value on flagship inventory during Q4.\n\n## Packaging\nBundle CTV pre-roll with display when a brief mentions video.",
      "notes": "Initial playbook, drafted from the Q4 sales deck.",
      "createdAt": "2026-07-28T15:04:00Z",
      "ownershipIssues": []
    },
    "pricing": {
      "currency": "USD",
      "facts": [
        {
          "id": "ctv-flagship",
          "label": "CTV flagship pre-roll",
          "appliesWhen": "Buyer requests CTV pre-roll on flagship shows",
          "pricing": {
            "pricingModel": "cpm",
            "currency": "USD",
            "targetPrice": 42,
            "floorPrice": 32
          },
          "strength": "hard_floor",
          "provenance": "2026 rate card, page 4"
        }
      ]
    }
  },
  "createdVersion": 3,
  "replacedVersion": 2
}

​

Discounts are per rule, not a whole list

{
  "discounts": {
    "rules": [
      {
        "houseDomain": "nike.com",
        "scope": "brand",
        "discountPercent": 12,
        "notes": "2026 Nike-house rate"
      },
      { "houseDomain": "wpp.com", "scope": "operator", "discountPercent": 8 }
    ],
    "remove": [{ "houseDomain": "coke.com", "scope": "brand" }]
  }
}

• A rule for a (houseDomain, scope) pair that doesn’t exist yet is created; one that does is updated. Sending a rule that already matches is a no-op and says so.
• Omitting notes keeps the note you already wrote. Send null to clear it.
• remove needs both halves of the key, because nike.com can carry a brand discount and an operator discount at once and they are different rules.
• Naming the same pair in rules and remove is rejected rather than resolved for you.

​

Which discount a buyer actually gets

{ "kind": "house_discount", "filter": { "buyerDomain": "converse.com" } }

​

business_rules — what you accept

{
  "briefAcceptancePolicy": "We do not accept gambling, tobacco, or political advertisers.",
  "creativePolicy": "Fast-food creative requires review before it goes live.",
  "notes": "Adds a review requirement for fast-food advertisers."
}

{
  "businessRules": {
    "creativeApproval": "manual",
    "mediaBuyApproval": "manual",
    "policy": {
      "version": 5,
      "content": "We do not accept gambling, tobacco, or political advertisers.\n\n<!-- scope3:business-rules:creative-policy -->\n\nFast-food creative requires review before it goes live.",
      "notes": "Adds a review requirement for fast-food advertisers.",
      "createdAt": "2026-07-28T15:10:00Z"
    }
  },
  "createdVersion": 5,
  "replacedVersion": 4
}

​

Turning off human review

{ "mediaBuyApproval": "auto", "acknowledgeNoHumanReview": true }

Moving media buys to `auto` means nobody reviews them, and your
create-time Brief Acceptance screen is also skipped. Pass
acknowledgeNoHumanReview: true to proceed.

​

Every save is create-and-activate

​

Rolling back: two routes, and the agent only has one of them

• Parts that already succeeded stay applied. A version that was created is live and is not rolled back, and the error still names createdVersion (and replacedVersion) so you know it exists before retrying.
• Parts that never ran are listed in unattempted, and the message names them. A pricing failure means your discounts were not read, created, changed or removed at all — so the retry guidance says to re-send pricing and discounts, and a content failure means neither of the other two was attempted and nothing is half-applied.
• Retry only what the response tells you to. Sending content again would mint a second, identical version rather than fixing anything.

​

Approval routing: who reviews, as opposed to whether anyone reviews

{ "kind": "business_rules", "include": ["approvalRouting"] }

{
  "approvalRouting": {
    "canManage": true,
    "managedBy": "open_approvals",
    "policies": [
      {
        "kind": "MEDIA_BUY",
        "primaryUsers": [
          { "id": "11", "name": "Ada Approver", "eligible": true }
        ],
        "fallbackUsers": [],
        "primaryRoles": ["ADMIN"],
        "fallbackRoles": [],
        "primaryChannels": ["in_app", "email"],
        "fallbackChannels": ["in_app"],
        "reminderAfterMinutes": 240,
        "escalateAfterMinutes": 1440,
        "version": 3
      }
    ],
    "eligibleRoles": [
      { "key": "ADMIN", "label": "Admins", "activeUserCount": 2 }
    ]
  }
}

​

Routing is changed on the Approvals Page, not by a tool

​

Searching version history and discount rules

{ "kind": "playbook_version", "query": "CTV" }

{
  "sources": ["objects"],
  "objects": {
    "kind": "playbook_version",
    "total": 3,
    "matched": 1,
    "returned": 1,
    "truncated": false,
    "results": [
      {
        "version": 3,
        "isActive": true,
        "notes": "Initial playbook, drafted from the Q4 sales deck.",
        "createdAt": "2026-07-28T15:04:00Z"
      }
    ]
  }
}