@adcp/sdk API Reference - v10.0.1
    Preparing search index...

    Interface ReportUsageRequest

    Reports how a vendor's service was consumed after campaign delivery. Used by orchestrators (DSPs, storefronts) to inform vendor agents (signals, governance, creative, or — when the receiving agent is the seller of the media buy itself — a sales agent for buyer-attested or vendor-attested billing reconciliation) what was used so the receiver can track earned revenue and verify billing. Records can span multiple accounts and campaigns in a single request. When the buy's measurement_terms.billing_measurement.vendor names a party other than the seller's own ad server, that party (or the buyer on its behalf) pushes final measurements via this task; the seller invoices against those final records. See Billing authority for the end-to-end flow.

    interface ReportUsageRequest {
        adcp_version?: string;
        adcp_major_version?: number;
        idempotency_key: string;
        reporting_period: DatetimeRange;
        usage: {
            account: AccountReference;
            media_buy_id?: string;
            vendor_cost: number;
            currency: string;
            pricing_option_id?: string;
            impressions?: number;
            media_spend?: number;
            signal_agent_segment_id?: string;
            standards_id?: string;
            rights_id?: string;
            creative_id?: string;
            build_variant_id?: string;
            property_list_id?: string;
            final?: boolean;
            finalized_at?: string;
            measurement_window?: string;
        }[];
        context?: ContextObject;
        ext?: ExtensionObject;
    }
    Index

    Properties

    adcp_version?: string

    Release-precision AdCP version (VERSION.RELEASE, e.g. "3.0", "3.1", "3.1-beta"). On a request: the buyer's release pin — the seller validates against its supported_versions and returns VERSION_UNSUPPORTED on cross-major mismatch, or downshifts to the highest supported release within the same major. On a response: the release the seller actually served — clients SHOULD validate the response against that release's schema, not against their pin. Patches are not negotiated; surface them as build_version on capabilities for operational visibility. When omitted, falls back to adcp_major_version (deprecated) or server default. Buyers SHOULD emit both adcp_version and adcp_major_version through 3.x to remain compatible with sellers that only read the legacy field. NORMALIZATION: SDKs that read full-semver values from bundle metadata (e.g. ComplianceIndex.published_version = "3.1.0-beta.1") MUST normalize to release-precision ("3.1-beta.1") before emitting on the wire — meta-field values are NOT valid wire values.

    adcp_major_version?: number

    DEPRECATED in favor of adcp_version (release-precision string). Servers MUST continue to honor this field through 3.x. Removed in 4.0. Original semantics: the AdCP major version the buyer's payloads conform to. Sellers validate against their supported major_versions and return VERSION_UNSUPPORTED if unsupported. When omitted, the seller assumes its highest supported version.

    idempotency_key: string

    Client-generated unique key for this request. If a request with the same key has already been accepted, the server returns the original response without re-processing. MUST be unique per (seller, request) pair to prevent cross-seller correlation. Use a fresh UUID v4 for each request. Prevents duplicate billing on retries.

    reporting_period: DatetimeRange
    usage: {
        account: AccountReference;
        media_buy_id?: string;
        vendor_cost: number;
        currency: string;
        pricing_option_id?: string;
        impressions?: number;
        media_spend?: number;
        signal_agent_segment_id?: string;
        standards_id?: string;
        rights_id?: string;
        creative_id?: string;
        build_variant_id?: string;
        property_list_id?: string;
        final?: boolean;
        finalized_at?: string;
        measurement_window?: string;
    }[]

    One or more usage records. Each record is self-contained: it carries its own account, allowing a single request to span multiple accounts.

    Type Declaration

    • account: AccountReference
    • Optionalmedia_buy_id?: string

      Seller-assigned media buy identifier. Links this usage record to a specific media buy.

    • vendor_cost: number

      Amount owed to the vendor for this record, denominated in currency.

      0

    • currency: string

      ISO 4217 currency code.

      ^[A-Z]{3}$

    • Optionalpricing_option_id?: string

      Pricing option identifier from the vendor's discovery response (e.g., get_signals, list_content_standards). The vendor uses this to verify the correct rate was applied.

    • Optionalimpressions?: number

      Impressions delivered using this vendor service.

      0

    • Optionalmedia_spend?: number

      Media spend in currency for the period. Required when a percent_of_media pricing model was used, so the vendor can verify the applied rate.

      0

    • Optionalsignal_agent_segment_id?: string

      Signal identifier from get_signals. Required for signals agents.

    • Optionalstandards_id?: string

      Content standards configuration identifier. Required for governance agents.

    • Optionalrights_id?: string

      Rights grant identifier from acquire_rights. Required for brand/rights agents. Links usage records to specific rights grants for cap tracking, billing verification, and overage calculation.

    • Optionalcreative_id?: string

      Creative identifier from build_creative or list_creatives. Required for creative agents. Links usage records to specific creatives for billing verification.

    • Optionalbuild_variant_id?: string

      Optional. When the reported creative_id was promoted from a specific build_creative variant leaf but the creative_id differs from the source build_variant_id, carry that source build_variant_id so billing reconciliation can link this usage record back to the exact produced leaf for audit (pricing_option_id alone is not unique across leaves). On the canonical path where creative_id is the build_variant_id, omit this field and use creative_id as the join key. Omit for creatives with no build-variant lineage.

    • Optionalproperty_list_id?: string

      Property list identifier from list_property_lists. Required for property list agents. Links usage records to specific property lists for billing verification.

    • Optionalfinal?: boolean

      Whether this usage record represents the reporter's final, billing-authoritative numbers for the reporting period. Absent means unknown — the reporter has not declared finality on this record. Set true only when the reporter has actually settled the numbers (e.g., 3PAS month-end close after SIVT scrubbing, conversion dedup, and view-through windows have closed; vendor file post-C7 for broadcast). Set false when pushing preliminary measurements (daily pacing pushes, intra-period progress) that are still settling. Receivers MUST NOT invoice on final: false records, and MUST NOT invoice on records where final is absent for buys whose measurement_terms.billing_measurement names this reporter as authoritative — request a final record first. Receivers MAY invoice on absent for buys with no measurement_terms.billing_measurement (3.0-style usage where the receiver treats reports as authoritative on receipt) and for non-media-buy variants (signals, governance, creative, brand — domains with no provisional state concept). When the same (account, media_buy_id, reporting_period) is later reported with final: true, that record supersedes any prior records for the period.

    • Optionalfinalized_at?: string

      ISO 8601 timestamp at which the reporter considered these numbers final. Present only when final: true. Anchors any deadline declared in the buy's measurement_terms.billing_measurement.finalization_deadline_hours.

      date-time

    • Optionalmeasurement_window?: string

      Which measurement window this record represents, referencing a window_id from the product's reporting_capabilities.measurement_windows or from measurement_terms.billing_measurement.measurement_window. Examples: 'c7' for broadcast TV, 'post_sivt' for digital post-IVT, 'downloads_30d' for podcast. When absent, the record is not windowed (standard digital reporting). When the buy's measurement_terms.billing_measurement.measurement_window is set, reporters SHOULD include measurement_window so the receiver can reconcile against the correct stage.

      50

    context?: ContextObject
    ext?: ExtensionObject