> ## Documentation Index > Fetch the complete documentation index at: https://docs.interchange.io/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 agent certification works, and how approved operators inspect buyer connections and source health. 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?** An advertiser or storefront that only uses an agent does not need a Partner account unless it also offers that agent to other companies. Partner is an organization-level account type alongside an organization's Buyer and Storefront accounts. Organization administrators can open the Partner page from the account selector or choose **Partner** under **Add account** to learn about the program, register an operator, and begin deterministic certification at no cost. Paid unrelated-client operations, contracted support, delegated debugging, and Partner-funded AI require the canonical `operate-agents-for-clients` entitlement. During public signup, choosing Partner opens the application path and does not grant that paid authority. The program gives approved 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 Interchange-defect or security intake remain available without it. The **Scope3 Embedded Sales Agent** is the reference implementation for explaining the certification journey. It is not represented as certified merely because Scope3 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 the Scope3 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. Scope3 may map a known provider operator and sales capability to your exact organization before your team completes registration. A mapped identity appears as **Scope3 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 Scope3 mapping provenance remains attached after a successful claim. 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 and lowercase SHA-256 artifact digest before supplying test evidence: ```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" } 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. 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. The paid 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. Paid operations are derived from the accepted `operate-agents-for-clients` entitlement, its selected payment authority, and billing standing; a workspace status label is not authority. Owning a private provider does not automatically grant unrelated-client operating rights. * **Interchange 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 paid 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`, account standing, 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. This decision covers only the paid right to operate across unrelated client organizations. It does not charge for or control the free Partner workspace, registration, testing, or certification, and it does not grant a listing, promotion, organic-ranking change, or Murph recommendation preference. ## Read the Partner account 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}/activate Authorization: Bearer ``` The operation first proves that the exact connection belongs to the authenticated provider organization. It 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 same 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. 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 } } } ] } ] } ] } ``` 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, a compatible card, invoice-credit, or funded ACH 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. 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. 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 Partner account. `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 Scope3-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 Partner account 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 Partner account 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. The Partner organization administrator 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 A registered Partner organization administrator 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 Scope3-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 Partner workspace. ## Reconcile Partner-authored AI usage A registered Partner organization administrator 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 Scope3 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 Scope3-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.