> ## Documentation Index > Fetch the complete documentation index at: https://docs.apostra.com/llms.txt > Use this file to discover all available pages before exploring further. # Partner Program and agent operations > Learn who the Partner Program is for, how free agent registration and certification work, and what commercial approval unlocks. The **Partner Program** is for companies that operate a sales agent on behalf of other businesses. A useful qualification question is: **Do you offer a sales agent that another company uses to sell media?** A buyer or seller that only uses an agent does not need to join the Partner Program unless it also offers that agent to other companies. The sales-agent offering belongs to the organization; it is not a third account beside the organization's Buyer and Seller accounts. Organization administrators can open the **Partner** page to learn about the program, register an operator, and begin deterministic certification at no cost. Some compatibility APIs still expose this organization-level offering as `accountType: PARTNER`; clients must not treat that projection as a separate account. Unrelated-client operation requires the canonical `operate-agents-for-clients` entitlement under accepted paid terms or an explicitly approved, time-bounded beta. Contracted support, delegated debugging, statements, Partner-funded AI, and promotion remain paid-only. The current product also gates public listing with Partner access; the planned Agent marketplace separates baseline truthful visibility from certification and commercial authority, but that marketplace picker is not available in Seller Setup yet. During public signup, choosing **Offer a sales agent to other sellers** creates the organization and starts sales-agent registration. After email verification, the administrator continues to registration; signup does not request or grant commercial approval to operate the agent for unrelated clients. The organization's Partner page gives agent operators a place to: * earn production certification from current evidence, including the zero-spend creative canary; * show buyers the identity and certification status of the production agent revision serving them; * inspect connected buyers, active results, source health, errors, latency, incidents, and ownership; and * use contracted Partner support for integrations, incidents, and buyer adoption after purchasing the right to operate agents for clients. Self-service certification and confirmed Apostra-defect or security intake remain available without it. The **Apostra Embedded Sales Agent** is the reference implementation for explaining the certification journey. It is not represented as certified merely because Apostra operates it: certification is awarded to a specific production revision only after every required assertion is current. The reference card reads its status from the same production-certification registry used for third-party agents. All authenticated organizations can read the customer-safe projection: ```http theme={null} GET /api/v2/provider/reference-agents/scope3-esa Authorization: Bearer ``` The response includes Apostra operator and SALES capability names, the current deployed production version, and its current certification decision. It never returns the image digest, evidence references, connected clients, source health, or private diagnostics. Before a real production artifact is registered, the release is `null` and the certification status is `REGISTERED`; the UI does not substitute the version pinned in source control or imply that deployment proves certification. ## Register your sales agent An organization administrator can register the provider and sales agent their company operates directly from the Partner page. Registration and deterministic certification are free; paid Partner Program approval is not required to create the technical identity or begin certification. Registering does not expose connected clients, grant operational access, activate a commercial relationship, or award certification. The page creates two durable records: * the **provider operator**, which is the provider name buyers know; and * the typed **SALES capability**, which is the sales agent offered to clients. Apostra may map a known provider operator and sales capability to your exact organization before your team completes registration. A mapped identity appears as **Apostra mapped · unclaimed**. It is only an identity map: it does not make the organization a Partner, certify the agent, authorize a client connection, or activate commercial status. A directly authenticated organization administrator can review and claim that mapping from Partner. Claiming preserves the existing operator UID, capability UID, client connections, and history. API clients can perform the same explicit, organization-scoped action: ```http theme={null} POST /api/v2/provider/registration/operators/{operatorUid}/claim Authorization: Bearer ``` An administrator cannot claim an operator mapped to a different organization. The original Apostra mapping provenance remains attached after a successful claim. There is one no-extra-login path for owned-and-operated supply. When an inventory Source is explicitly bound to a SALES capability whose provider owner and Source client resolve to the same effective organization, that binding is the ownership confirmation. Apostra marks the mapped operator claimed as part of the audited binding operation; an administrator does not also have to open Partner and claim it. Parent and child accounts under the same organization count as first-party. The same attributed binding records the first-party client request and provider acceptance, so the organization does not approve both sides of its own connection. Configuration, authorization, validation, certification, health, and quarantine gates remain separate. Endpoint or domain similarity alone never creates ownership. If the account hierarchy later changes so the Source and provider no longer share an effective organization, Apostra removes only the claim, registration, request, and acceptance facts created by this shortcut. An explicit provider claim, registration, or pre-existing client request remains durable; otherwise both sides complete the cross-organization workflow. This shortcut does not apply when another organization operates the Agent. Those cross-organization connections still require the provider to claim its identity, accept the client, and complete the applicable Partner connection workflow. It also does not apply to official adapters or embedded ad-server Sources. Attaching identity must not interrupt a cross-organization Source that was already serving before this Partner workflow existed. When the binding audit records that the Source was already active, Apostra keeps that legacy Source serving while the provider adopts the newer lifecycle. The Agent mapping and the operator ownership claim are separate: Apostra can record the exact Agent backing the Source while its operator remains unclaimed. This compatibility state does not claim the Agent, mark the connection accepted or activated, award certification, grant paid Partner authority, or authorize another Source. New and previously inactive client connections must complete the normal authorization, acceptance, validation, certification, and activation workflow before they can serve. API clients can use the same organization-scoped workflow: ```http theme={null} GET /api/v2/provider/registration Authorization: Bearer POST /api/v2/provider/registration/operators Authorization: Bearer Content-Type: application/json {"displayName":"Acme Agent Company"} POST /api/v2/provider/registration/operators/{operatorUid}/capabilities Authorization: Bearer Content-Type: application/json {"type":"SALES","displayName":"Acme Sales Agent"} ``` Certification applies to an immutable implementation revision, not merely the provider name or endpoint. Register the exact revision, lowercase SHA-256 artifact digest, and its credential-free HTTPS endpoints before supplying test evidence. A revision accepts at most 16 endpoint declarations; endpoint keys must be unique within that revision. The `endpoints` list is optional, so existing registrations do not need to change. Each declaration requires: * `endpointKey`: 3–128 characters, beginning with a letter or number and then using only letters, numbers, `.`, `_`, `:`, `/`, `+`, or `-` * `displayName`: 1–255 characters * `endpointUri`: a valid HTTPS URL of at most 2,048 characters, without a username or password. The scheme is case-insensitive and is stored as lowercase `https://`; the host, port, path, query, and fragment remain otherwise exact (including an `@` in the path). ```http theme={null} POST /api/v2/provider/registration/capabilities/{capabilityUid}/revisions Authorization: Bearer Content-Type: application/json { "revisionKey":"acme-sales-2026.08.1", "artifactDigest":"sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef", "implementationVersion":"2026.08.1", "endpoints":[ { "endpointKey":"sales-mcp", "displayName":"Acme Sales Agent", "endpointUri":"https://agent.acme.example/mcp" } ] } POST /api/v2/provider/registration/capabilities/{capabilityUid}/deployments Authorization: Bearer Content-Type: application/json { "revisionUid":"70000000-0000-4000-8000-000000000001", "deploymentRef":"deployment-2026-08-04.1" } ``` The deployment reference must uniquely identify the production rollout. Reusing the same reference for the same revision is safe; reusing it for another revision is rejected. An explicit rollback appends another deployment event for the older revision, making that revision current without copying certification evidence. ### Attest an endpoint for an observed revision An observed production revision can be missing an endpoint declaration even when its immutable observation and deployment provenance are valid. A directly authenticated organization account administrator may append one endpoint attestation for that exact, current observed revision. This does not change the revision key, artifact digest, or deployment history. The attestation endpoint is available only when the revision is current for the SALES capability and the supplied endpoint URI matches the active, tenant-owned SALES source after lowercasing its HTTPS scheme only. Its host, port, path, query, and fragment are otherwise compared as supplied. The URI must be credential-free HTTPS with no query or fragment component. The endpoint key and display name are recorded with the attestation; credentials are never accepted by this API. ```http theme={null} POST /api/v2/provider/registration/capabilities/{capabilityUid}/observed-revision-endpoint-attestations Authorization: Bearer Content-Type: application/json { "revisionUid":"70000000-0000-4000-8000-000000000001", "inventorySourceId":"123", "endpointKey":"sales-mcp", "displayName":"Acme Sales Agent", "endpointUri":"https://agent.acme.example/mcp", "idempotencyKey":"80000000-0000-4000-8000-000000000001" } ``` `capabilityUid`, `revisionUid`, and `idempotencyKey` are UUIDs. `inventorySourceId` is a positive decimal PostgreSQL BIGINT. The capability, revision, and source must still belong to the authenticated organization, and the source must be the current active SALES source for the supplied endpoint. The API canonicalizes only the case of the `https://` scheme before comparing the URI to that source. It does not normalize the host, port, path, query, or fragment. The attestation request itself rejects credentials, query strings, and fragments, so use the exact credential-free source URI without those components. A successful request returns HTTP 200: ```json theme={null} { "data": { "attestationUid": "90000000-0000-4000-8000-000000000001", "endpointUid": "a0000000-0000-4000-8000-000000000001", "createdAt": "2026-09-22T07:00:00.000Z", "replayed": false }, "error": null } ``` `replayed` is `true` when the same request is repeated with the same `idempotencyKey`; the response then returns the original attestation and endpoint identifiers. Reusing a key for different values, providing an invalid UUID or source ID, providing a URI with credentials, a query string, or a fragment, or attempting to attest a revision that already has an endpoint is rejected. An endpoint attestation supplies endpoint provenance only. It does not register or certify a revision, create a fixture, request an evaluation, activate a source, dispatch a test, or authorize a transaction. Those controls remain separate and must be satisfied independently. These writes require a directly authenticated organization account administrator. They cannot be performed through a service token or a staff-assisted impersonation session. A later deployment revision starts with its own evidence state and cannot inherit certification from an earlier one. ### When fixture setup has no eligible option Fixture setup evaluates the exact current production revision in this order: an endpoint declaration, an active SALES source with the same endpoint, and an active current source account. If there are no options, Interchange reports one safe reason without returning source-account or endpoint details: * `NO_ENDPOINT_FOR_CURRENT_PRODUCTION_REVISION` - a directly authenticated Account Admin can use **Attest current endpoint** from the Agent task, then enter and confirm the credential-free HTTPS endpoint, endpoint key, and display name. The task generates one idempotency key and reuses it if the request needs a retry. * `NO_MATCHING_ACTIVE_SALES_SOURCE` - the current revision has an endpoint, but no active SALES source matches it exactly. * `NO_ACTIVE_CURRENT_SOURCE_ACCOUNT` - the matching source has no active current source account. Attesting an endpoint never creates a fixture, starts evaluation, changes paid membership, or authorizes a purchase. Fixture registration and certification remain separate protected steps. ## Upgrade a private agent to Partner operations A private first-party sales agent and a Partner-operated sales agent are the same durable agent identity. Upgrading changes who the agent is commercially authorized to serve; it does not create a second agent, convert an inventory Source to another type, or replace the Source-to-agent bindings already in use. Existing first-party Sources continue to work as first-party relationships. Open the agent from **Agents**, then use **Who this Agent can serve**. The card shows four independently evaluated prerequisites: provider ownership, Partner registration, production certification, and operating standing. Operating standing comes from accepted paid/payment authority or an unexpired beta; an active billing hold blocks both. Its primary action takes the organization to the exact unresolved step. When all four are ready, the same agent may accept explicitly authorized Sources belonging to unrelated client organizations. On the **Partner** page, select **Join the certification partner program** to review an issued private offer in **Plan & Billing**. The offer shows its exact price, currency, term, and version before an organization administrator accepts it. If payment authority is missing, the accepted offer continues to the secure payment-method setup. If no private offer has been issued, the page directs the organization to request commercial terms. Registering an agent and completing certification remain free throughout this process. Every unrelated-client Source still requires its own explicit client authorization, provider acceptance, validation, and activation. Partner access does not infer a relationship from a shared endpoint or domain, and it does not give the provider access to Sources that have not been bound to its agent. ## Invite a client Storefront An entitled Partner administrator can choose **Invite a client Storefront** from a Sales Agent's **Inventory sources** section, or **Add a client** in Partner operations. Starting from an Agent opens the same invitation ledger with that exact Agent selected and its pending invitations in view. Enter the publisher name, bare publisher domain, and contact email. Apostra emails the contact a time-limited invitation and shows it as **Not started** until it is accepted. The invitation does not create a publisher account. The publisher follows the link and either creates its own organization or signs in to an existing one. A direct administrator then accepts the referral for that organization, selects an exact Agent Source owned by that organization, and explicitly authorizes the attachment. The Source binding, client request, and client consent are written atomically. The publisher remains responsible for its own credentials, payout setup, publisher domains, and `adagents.json`; Optimera or another Partner never receives its secret values. Accepting a referral links only the onboarding request. It does not create a Source, share credentials, record provider acceptance, or activate the connection. The next publisher action selects the exact Source and records the cross-organization binding and publisher consent. Credentials, payout setup, Partner acceptance, validation, and activation remain independent and appear independently in the publisher lifecycle. Partner administrators can also create and list referrals through the API: ```http theme={null} POST /api/v2/provider/account/client-referrals GET /api/v2/provider/account/client-referrals Authorization: Bearer ``` ```json theme={null} { "capabilityUid": "30000000-0000-4000-8000-000000000001", "publisherName": "Example Publisher", "publisherDomain": "publisher.example", "contactEmail": "owner@publisher.example" } ``` The public preview accepts the invitation token in the request body and returns the Partner name, Agent name, intended publisher, invitation status, and expiry. It is rate-limited and does not return the contact email or publisher account data: The email link initially carries the bearer so the browser can open the invitation. Before analytics or error telemetry initialize, Apostra moves a valid bearer to same-tab session storage and removes it from the visible URL. Login and signup redirects point back to the clean `/client-referral` path and never copy the bearer into their query strings. ```http theme={null} POST /api/v2/provider/client-referrals/preview Content-Type: application/json {"token":"<43-character-invitation-token>"} ``` After signing in, a direct publisher administrator accepts the referral for the current organization. `setup` then returns that organization's eligible Agent Sources and the exact completed attachment, if one already exists: ```http theme={null} POST /api/v2/provider/client-referrals/accept POST /api/v2/provider/client-referrals/setup Authorization: Bearer Content-Type: application/json {"token":"<43-character-invitation-token>"} ``` Completing onboarding requires both the token and one Source selected from the `setup` response: ```http theme={null} POST /api/v2/provider/client-referrals/complete Authorization: Bearer Content-Type: application/json { "token": "<43-character-invitation-token>", "inventorySourceId": "12345" } ``` `setup` returns only Agent Sources owned by the organization that accepted the referral. `complete` accepts one global `inventorySourceId`, rechecks the publisher organization and Partner capability inside the transaction, requires a cross-organization relationship, and records the exact binding and consent. Production certification remains attached to the Agent's exact implementation revision, not repeated for each referral. Connection validation, runtime health, products, campaigns, and reporting remain publisher-specific. The Partner operations view gives an authorized provider operator a source-by-source view of the client inventory explicitly connected to its capabilities. The free workspace, registration, and certification views remain available without the `operate-agents-for-clients` entitlement. The operational view keeps these concepts separate: * **Provider ownership** identifies the organization that operates a provider and its capabilities. * **Partner registration** records the free program registration. Operating authority is derived from `operate-agents-for-clients` plus either accepted payment authority or an unexpired beta, with no billing hold; a workspace status label is not authority. Owning a private provider does not automatically grant unrelated-client operating rights. * **Apostra production certification** evaluates the exact latest implementation revision against the current required-assertion policy. It is not purchased through Partner status. * **Client connections** record the client's request and authorization, the provider's acceptance, validation, activation, quarantine, and connection revocation as distinct facts. * **Runtime health** comes from each connected inventory source and can differ between clients using the same certified implementation. A child account uses its parent organization's entitlement and switches to that organization before opening Partner operations. ## Check Partner operations access An organization administrator can read the effective decision before opening or activating an unrelated-client connection: ```http theme={null} GET /api/v2/provider/partner-access Authorization: Bearer X-SCOPE3-CUSTOMER-ID: ``` The response reports `state`, `allowed`, whether paid authority is contract-backed (`purchased`), account standing and its `authority`, ownership, certification readiness, denial reasons, and the next action. During the v2 compatibility window, `featureKey` remains `partner-program-participation` for existing API clients and the additive `entitlementFeatureKey` is `operate-agents-for-clients`. Older API deployments may omit `entitlementFeatureKey`, so clients should continue accepting the legacy `featureKey` and prefer `entitlementFeatureKey` when it is present. The access response makes paid and beta authority explicit. `purchased: true` means the entitlement is backed by accepted paid terms. A temporary beta instead returns `purchased: false`, `standing.authority: "BETA"`, and its deadline in `entitlementExpiresAt`: ```json theme={null} { "state": "GRANTED", "allowed": true, "purchased": false, "entitlementFeatureKey": "operate-agents-for-clients", "entitlementExpiresAt": "2026-10-01T00:00:00.000Z", "standing": { "usable": true, "reason": null, "authority": "BETA" } } ``` Apostra staff grant or revoke a beta for the effective billing organization; a child account inherits that decision from its parent. The grant requires a future expiry and an audit reason. Revocation or expiry removes beta authority immediately, while an independent paid authority can continue to allow access. While beta authority is active, the Partner operations page shows an informational **Temporary beta operating access** banner above the connected source fleet. The banner distinguishes the beta from purchased access and notes that paid support, statements, delegated debugging, and Partner-funded AI are not included. The page refreshes the access decision as the recorded expiry approaches. At expiry, the beta banner and operational fleet are removed unless another paid authority still grants access; free registration and certification remain available. `standing.authority: "BETA"` means temporary operation is approved only until the entitlement's recorded expiry. It creates no pricing, payment schedule, support, SLA, renewal, listing, promotion, legal, notice, or wind-down promise. Ownership, registration, current production certification/readiness, explicit authorization for every client Source, tenant isolation, and billing holds continue to apply. Contracted support, delegated diagnostics, support/AI statements, and Partner-funded AI remain unavailable until paid terms authorize them. This decision covers only the paid or time-bounded-beta right to operate across unrelated client organizations. It does not charge for or control the free sales-agent registration view, registration, testing, or certification, and it does not grant a listing, promotion, organic-ranking change, or Murph recommendation preference. ## Read Storefront capability configuration The Storefront account response is a separate contract from the sales-agent offering projection below. Read it with: ```http theme={null} GET /api/v2/storefront Authorization: Bearer ``` In that response, `configuredCapabilities` is the seller's persisted declaration, while `capabilities` is the effective public projection clients can rely on. The effective value can differ because it is derived from the declared flags together with Source topology, embedded ad-server locking, product-composition mode, adapter routing, and approval settings. Use `configuredCapabilities` to display or compare saved configuration; use `capabilities` for buyer-facing and runtime decisions. A successful configuration write does not by itself guarantee that the effective public capability changed. ## Read the sales-agent offering projection Use the authenticated endpoint that backs the page: ```http theme={null} GET /api/v2/provider/account?windowHours=168 Authorization: Bearer ``` `windowHours` defaults to `168` and accepts values up to `720`. It controls the observation window used for source-level call and failure metrics. An organization administrator can activate or refresh one connection after its setup is ready: ```http theme={null} POST /api/v2/provider/account/connections/{bindingUid}/accept POST /api/v2/provider/account/connections/{bindingUid}/validate POST /api/v2/provider/account/connections/{bindingUid}/activate Authorization: Bearer ``` `accept` requires a directly authenticated Partner administrator and an active publisher authorization for the exact binding. It records Partner acceptance and immediately starts the same retryable validation available through `validate`; acceptance does not imply that validation passed or that activation occurred. Validation checks the current contract, authorization, production certification (including tenant-isolation evidence), health, and credential reference, then forces an authenticated live capability probe against the exact publisher Source. A failed or interrupted run remains retryable; a stale in-progress lease is never a permanent lock. `activate` first proves that the exact connection belongs to the authenticated provider organization, then rechecks approval, setup, certification, health, organization relationship, and Partner standing in one transaction. A blocked response identifies who owns the next step. Providers can use the activation operation to refresh the bounded first-party organization check immediately; an automatic worker refreshes the oldest page of up to 5,000 current connection attestations with one bounded bulk organization lookup on a one-minute cadence. No credential value is read or returned. Partner administrators can read the same source-scoped delivery reporting used by standard Storefront connections without entering the publisher account: ```http theme={null} GET /api/v2/provider/account/connections/{bindingUid}/reporting?days=30&view=summary Authorization: Bearer ``` The endpoint first proves that the exact binding belongs to the authenticated Partner and still has active publisher authorization, derives the client customer and Source server-side, and carries the exact Source through both the Postgres media-buy projection and BigQuery delivery filter. It does not accept a client customer or Source override. Use `days` from 1 to 90 (default 7), or `startDate` and `endDate` in `YYYY-MM-DD` format. `view=summary` returns the advertiser, media-buy, and package hierarchy; `view=timeseries` returns daily rows. `sourceBreakdown=true` splits timeseries rows by contributing Source. Partner reporting always disables demo and download modes and cannot override the Source selected by the binding. The response groups explicitly connected client sources under the provider capability they use: ```json theme={null} { "generatedAt": "2026-08-03T12:00:00.000Z", "projection": { "rowLimit": 2000, "truncated": false, "incidentRowLimit": 2000, "incidentsTruncated": false }, "ownerOrganization": { "customerId": 42, "name": "Acme Media", "company": "Acme Media" }, "workspace": { "registrationStatus": "REGISTERED", "commercialStatus": "ACTIVE" }, "operators": [ { "operatorUid": "20000000-0000-4000-8000-000000000001", "displayName": "Acme operator", "capabilities": [ { "capabilityUid": "30000000-0000-4000-8000-000000000001", "type": "SALES", "displayName": "Acme sales", "certification": { "assertionKey": "creative_sync_format_negotiation", "status": "PASSED", "observedAt": "2026-08-03T10:00:00.000Z", "expiresAt": "2026-09-02T10:00:00.000Z" }, "productionCertification": { "policyVersion": "interchange-sales-production-v1", "status": "TESTING", "current": false, "revisionUid": "70000000-0000-4000-8000-000000000001", "revisionKey": "acme-sales-2026.08.1", "certifiedAt": null, "expiresAt": null, "summary": { "required": 7, "passed": 1, "actionRequired": 6 }, "requirements": [ { "assertionKey": "creative_sync_format_negotiation", "status": "PASSED", "observedAt": "2026-08-03T10:00:00.000Z", "expiresAt": "2026-09-02T10:00:00.000Z" }, { "assertionKey": "media_buy_transaction", "status": "MISSING", "observedAt": null, "expiresAt": null } ] }, "summary": { "connectedSources": 1, "activeSources": 1, "healthySources": 1, "degradedSources": 0, "unhealthySources": 0, "unknownSources": 0, "quarantinedSources": 0 }, "incidents": [ { "incidentUid": "60000000-0000-4000-8000-000000000001", "classification": "IMPLEMENTATION_REGRESSION", "attributedOwner": "PROVIDER", "attributionConfidence": 0.9, "code": "UPSTREAM_UNAVAILABLE", "summary": "One provider implementation revision is failing across endpoints.", "firstDetectedAt": "2026-08-03T11:45:00.000Z", "updatedAt": "2026-08-03T11:55:00.000Z", "revisionUid": "70000000-0000-4000-8000-000000000001", "endpointUid": null, "affectedConnectionUids": [ "80000000-0000-4000-8000-000000000001" ], "affectedClientCount": 1 } ], "sources": [ { "bindingUid": "40000000-0000-4000-8000-000000000001", "sourceId": "inventory-source-7", "sourceName": "Client storefront", "client": { "customerId": 84, "name": "Client Media", "company": "Client Media" }, "connection": { "clientRequestedAt": "2026-08-03T09:00:00.000Z", "clientAuthorizedAt": "2026-08-03T09:01:00.000Z", "providerAcceptedAt": "2026-08-03T09:02:00.000Z", "validation": { "status": "PASSED", "observedAt": "2026-08-03T09:03:00.000Z", "errorCode": null, "errorSummary": null, "owner": null }, "activatedAt": "2026-08-03T09:04:00.000Z", "activationCurrent": true, "quarantinedAt": null, "revokedAt": null }, "health": { "status": "healthy", "previousStatus": "degraded", "observedAt": "2026-08-03T11:55:00.000Z", "lastOkAt": "2026-08-03T11:55:00.000Z", "error": null, "metrics": { "callCount": 120, "failureCount": 1, "failureRate": 0.0083, "p95LatencyMs": 184 } }, "products": { "total": 12, "available": 10 }, "campaigns": { "total": 4, "active": 2 } } ] } ] } ] } ``` The example shortens some nested objects for readability. Treat the API response as the source of truth for nullable lifecycle fields. `activatedAt` is historical evidence; only `activationCurrent: true` means that activation belongs to the current, unrevoked client-authorization epoch. `activationCurrent` is deliberately stricter than “the client once approved.” It is true only while the exact authorization grant, external-agent configuration, Partner connection contract, latest certified implementation revision, provider acceptance, post-authorization validation, source health, and quarantine state are all current. An unrelated client also requires a claimed provider identity, an in-force `operate-agents-for-clients` entitlement, either compatible card, invoice-credit, or funded ACH authority for paid access or unexpired `BETA` operating authority, and no billing hold; a verified first-party organization connection does not. If any one of those facts changes, `activationCurrent` becomes false while `activatedAt` continues to show the historical event. First-party eligibility is re-resolved from the organization hierarchy and held only as a five-minute database-owned attestation. The automatic reconciliation worker refreshes an indexed, oldest-first page of up to 5,000 current connections on a one-minute cadence through the same governed activation boundary. It alerts when the oldest page crosses a four-minute capacity margin, and a separate bounded page keeps activation repair progressing. Source status convergence uses its own 5,000-source rotating keyset page. If repeated bounded lookups cannot refresh an attestation, the connection fails closed; if the client is now unrelated, the active Partner commercial requirement applies immediately on revalidation. The same worker moves an inventory source to `PENDING` when any activation gate becomes false, so the source cannot continue serving on a stale lifecycle status. During historical Source reconciliation, an already-active first-party Source is not demoted merely because its durable provider identity is added. Its existing health, validation, certification, and quarantine facts remain unchanged. A new Source, a cross-organization binding, or a Source already in `PENDING` still follows the normal activation gates. Credential values and secret references are never part of this response. The activation check uses only whether the client-owned connection has the type-compatible credential reference required by its selected authentication method. ## Read production certification `productionCertification` is the overall, policy-versioned decision for the exact `revisionUid`. The first `SALES` policy requires current production evidence for catalog and product quality, authentication and tenant isolation, a media-buy transaction, creative-format negotiation, reporting and reconciliation, reliability and recovery, and operational ownership. The status is: * `REGISTERED` when the capability has not registered an implementation revision; * `TESTING` while any required assertion is missing, failed, or invalidated; * `CERTIFIED` only while every required assertion is currently passing; * `EXPIRED` when required passing evidence has expired; * `REVOKED` when a required assertion has been revoked; or * `NOT_AVAILABLE` for a capability type whose production suite is not yet available. `certifiedAt` is the time the last required assertion passed. `expiresAt` is the earliest expiry across the required passing evidence, so the decision fails closed when any required proof becomes stale. Staging evidence and evidence from a superseded suite version do not satisfy the production policy. For operational-ownership evidence, a Partner connection contract can name one operating contact and the `PROVIDER_FLEET_INBOX` incident route. A protected test rechecks that the named user is currently entitled to the provider-owning organization's inbox, then binds that result to the exact contract version, implementation revision, fixture, and cleanup-confirmed run. This proves platform inbox reachability only. It does not send an incident, prove an email or webhook was delivered, or prove that a recipient acknowledged it. A missing, changed, or no-longer-entitled contact leaves the assertion unproven. The adjacent `certification` object remains the exact `creative_sync_format_negotiation` canary assertion. It explains that one requirement and must not be presented as the overall certification result. The projection reads at most 2,000 joined connection rows per request and reports that ceiling in `projection.rowLimit`. When `projection.truncated` is `true`, the page warns that its per-capability source totals are partial rather than presenting them as complete. The response returns at most `projection.incidentRowLimit` active incidents across the organization's sales-agent offering. `projection.incidentsTruncated` warns when additional incidents exist. An incident is opened only after a non-healthy source signal persists for five minutes. It groups failures by the smallest supported fault domain: one client connection, one endpoint, one implementation revision, or the full provider capability. As more connections become affected, they join the existing incident rather than creating duplicate incidents. Incident attribution is evidence, not an enforcement decision. `attributedOwner` can be `PROVIDER`, `CLIENT`, `SCOPE3`, or `UNKNOWN`; `attributionConfidence` communicates how strongly the current source observations support that owner. Recovery and attribution changes append new evidence without rewriting prior conclusions. ## Interpret health safely Health is computed per connected inventory source from that source's observations. A healthy sibling does not hide another source's failure, and the creative canary assertion does not become a general account-health badge. Errors expose a safe code, summary, owner (`CLIENT`, `PROVIDER`, or `SCOPE3`), and an optional correlation reference for provider-owned remediation. Client-owned and Apostra-owned lifecycle details remain generic in the provider view; their raw summaries and correlation references are not returned. The projection does not return credentials, raw upstream payloads, or inventory belonging to unrelated clients. Missing provider acceptance, inactive Partner eligibility when required, contract/configuration drift, and malformed or expired certification evidence fail closed. An administrator can use the corresponding inventory-source diagnostics view to confirm which capability a source is mapped to, whether the provider accepted it, and whether the connection is active or quarantined. Provider topology comes from the explicit capability, implementation revision, endpoint, connection, and deployment records. The sales-agent offering projection does not infer provider ownership or deployment identity from `adcp_agent`, source URLs, or coincidental domains. ## Delegate one source for debugging A client organization administrator can invite the certified Partner already connected to one inventory source to inspect that source's safe diagnostics. Create the invitation through the Storefront API: ```http theme={null} POST /api/v2/provider/debug-grants Authorization: Bearer Content-Type: application/json { "bindingUid": "40000000-0000-4000-8000-000000000001", "expiresAt": "2026-08-05T12:00:00.000Z", "reason": "Investigate repeated provider timeouts" } ``` Use the exact `bindingUid` returned for the source in the sales-agent offering or diagnostics projection; a display `sourceId` is not an authority identifier. `expiresAt` must be in the future and no more than seven days away. The API derives the Partner and source from that active capability connection; the client cannot nominate another organization. The capability must have current production certification, the provider identity must be claimed, and the Partner contract and payment standing must be current. An administrator of the organization enrolled in the Partner Program lists current invitations and reads one source's diagnostics with its own organization token: ```http theme={null} GET /api/v2/provider/debug-grants GET /api/v2/provider/debug-grants/{grantUid}/diagnostics?windowHours=48 Authorization: Bearer ``` The diagnostics response uses the same redacted source-health contract as the client view, with legacy agent identity removed. It does not include credentials or unrelated clients. It does not permit source changes, test execution, client account membership, or shared-room access. The client can end access immediately: ```http theme={null} POST /api/v2/provider/debug-grants/{grantUid}/revoke Authorization: Bearer Content-Type: application/json { "reason": "Debugging window closed" } ``` Every list and diagnostics request rechecks the current connection, production certification, Partner status, expiry, and revocation. If any check stops passing, the invitation is no longer visible or usable. ## Reconcile support effort An administrator of an organization registered in the Partner Program can retrieve an operational statement of support effort attributed to its explicitly connected client sources: ```http theme={null} GET /api/v2/provider/support-statement?from=2026-08-01T00:00:00.000Z&to=2026-09-01T00:00:00.000Z Authorization: Bearer ``` Both timestamps are required. The period is half-open (`from` inclusive, `to` exclusive) and can cover at most 93 days. The response includes full-period minute totals and up to 500 recent detail lines. `projection.truncated` indicates when more lines exist; totals still cover the complete requested period. Each line is attributed through one immutable `bindingUid` to the Partner capability, client organization, Storefront, and inventory source. It includes a category (`ONBOARDING`, `CERTIFICATION`, `DEBUGGING`, or `INCIDENT_RESPONSE`) and a rating disposition: * `INCLUDED` records effort treated as included support. * `OVERAGE_CANDIDATE` records effort for later reconciliation. It is not a price, invoice line, accepted commercial term, or client charge. * `ZERO_RATED_SCOPE3_DEFECT` records incident-response effort excluded because a confirmed Apostra-owned platform defect affected that exact connection. Zero-rating requires an authoritative Partner-account incident whose latest attribution is `SCOPE3_DEFECT` / `SCOPE3` and whose latest connection-membership evidence at the time the effort occurred says that the connection was attached. Staff cannot mark arbitrary support effort as zero-rated. Entries are append-only, idempotent operating evidence; corrections add new evidence rather than rewriting history. Only explicitly Partner-safe descriptions and evidence references appear in the statement. It does not expose credentials, raw incident payloads, internal staff notes, unrelated client inventory, prices, or billing records. Child organizations must switch to the registered parent organization. ## Reconcile Partner-authored AI usage An administrator of an organization registered in the Partner Program can retrieve AI usage produced by assisted testing and Partner-authored debugging for its explicitly connected sources: ```http theme={null} GET /api/v2/provider/ai-usage-statement?from=2026-08-01T00:00:00.000Z&to=2026-09-01T00:00:00.000Z Authorization: Bearer ``` The period follows the same half-open, 93-day maximum as the support statement. The response returns full-period event/token totals and at most 500 recent detail lines. Each line retains the exact capability, implementation revision, `bindingUid`, client, Storefront source, Partner-safe session reference, and any confirmed Apostra incident used for zero-rating. This launch records two dispositions: * `TRACKED_NOT_BILLED` measures Partner-authored AI COGS but settles zero IUs. * `ZERO_RATED_SCOPE3_DEFECT` additionally proves that the exact connection was affected by a confirmed Apostra-owned defect when the usage occurred. Both dispositions are structurally platform-bearer and return `iuAmountMilli: 0`. No Partner activity term has been accepted yet, so the attribution cannot debit the Partner or client IU wallet, create an invoice line, or imply a future price. A later paid activity requires its own accepted Effective Rate Card term and entitlement before the producer can move off this dark rail. Normal client Buyer or Storefront workloads remain attributed to the client even when a Partner capability participates. Deterministic conformance, certification, and routine health checks produce no AI usage row. The Partner statement does not expose model/vendor cost, raw prompts, credentials, internal notes, or unrelated client inventory.