@adcp/sdk API Reference - v14.3.0
    Preparing search index...

    Interface ReportingReconciliationClient

    interface ReportingReconciliationClient {
        getReportingStatus(
            params: GetReportingStatusRequest,
            options?: { signal?: AbortSignal },
        ): Promise<GetReportingStatusResponse>;
        syncReportingReceipts(
            params: SyncReportingReceiptsRequest,
            options?: { signal?: AbortSignal },
        ): Promise<SyncReportingReceiptsResponse>;
        syncReportingStatus?(
            params: {
                account?: CanonicalAccountReference;
                idempotency_key: string;
                statuses: Record<string, unknown>[];
            },
            options?: { signal?: AbortSignal },
        ): Promise<{ status?: string; results?: unknown[] }>;
        getMediaBuyDelivery?(
            params: {
                account?: CanonicalAccountReference;
                reporting_revision_id: string;
                pagination?: { cursor?: string };
            },
            options?: { signal?: AbortSignal },
        ): Promise<
            {
                status?: string;
                reporting_revision_binding?: {
                    reporting_revision_id?: string;
                    row_count?: number;
                    control_totals?: ReportingControlTotal[];
                    content_sha256?: string;
                };
                reporting_rows?: unknown[];
                pagination?: {
                    has_more?: boolean;
                    cursor?: string;
                    total_count?: number;
                };
            },
        >;
    }
    Index
    getReportingStatus syncReportingReceipts syncReportingStatus? getMediaBuyDelivery?

    • rc.3 consumer-status loop. Optional so existing adopters keep working: when it is absent the reconciler still plans every status and reports it on the result, it just cannot post. Supply it only against a seller that advertises consumer_status_task.

      Parameters

      • params: {
            account?: CanonicalAccountReference;
            idempotency_key: string;
            statuses: Record<string, unknown>[];
        }
      • Optionaloptions: { signal?: AbortSignal }

      Returns Promise<{ status?: string; results?: unknown[] }>

    • Exact-revision read, the only way a buyer can earn a received statement.

      observed_revision_content_sha256 is defined as the binding digest "independently recomputed from the exact consumed Core revision binding". Copying the seller's own revision_content_sha256 out of the ledger would hand that digest back unverified and turn buyer-attributed arrival evidence into an echo. So the reconciler pages reporting_rows for the exact revision, concatenates them in cursor order, and recomputes SHA-256(JCS({reporting_revision_id,row_count,control_totals,reporting_rows})) itself.

      Optional: without it the reconciler still plans received and content_mismatch, but marks them suppressed: 'consumption_unavailable' and posts neither. Attesting consumption we did not perform is the one outcome worse than staying silent.

      Parameters

      • params: {
            account?: CanonicalAccountReference;
            reporting_revision_id: string;
            pagination?: { cursor?: string };
        }
      • Optionaloptions: { signal?: AbortSignal }

      Returns Promise<
          {
              status?: string;
              reporting_revision_binding?: {
                  reporting_revision_id?: string;
                  row_count?: number;
                  control_totals?: ReportingControlTotal[];
                  content_sha256?: string;
              };
              reporting_rows?: unknown[];
              pagination?: { has_more?: boolean; cursor?: string; total_count?: number };
          },
      >

    Settings
    Member Visibility

    On This Page
    Methods