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

    Interface UpdateMediaBuyRequest

    Request parameters for updating campaign and package settings

    interface UpdateMediaBuyRequest {
        adcp_version?: string;
        adcp_major_version?: number;
        account: AccountReference;
        media_buy_id: string;
        revision?: number;
        paused?: boolean;
        canceled?: true;
        cancellation_reason?: string;
        start_time?: string;
        end_time?: string;
        packages?: PackageUpdate[];
        invoice_recipient?: BusinessEntity;
        new_packages?: PackageRequest[];
        reporting_webhook?: ReportingWebhook;
        push_notification_config?: PushNotificationConfig;
        idempotency_key: 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.

    media_buy_id: string

    Seller's ID of the media buy to update

    revision?: number

    Expected current revision for optimistic concurrency. Optional for backward compatibility. When provided, sellers MUST reject the update with CONFLICT if the media buy's current revision does not match, and MUST enforce that comparison atomically with the write. Obtain from get_media_buys or the most recent create/update response.

    1

    paused?: boolean

    Pause/resume the entire media buy (true = paused, false = active)

    canceled?: true

    Cancel the entire media buy. Cancellation is irreversible — canceled media buys cannot be reactivated. Sellers MAY reject with NOT_CANCELLABLE if the media buy cannot be canceled in its current state.

    cancellation_reason?: string

    Reason for cancellation. Sellers SHOULD store this and return it in subsequent get_media_buys responses.

    500

    start_time?: string
    end_time?: string

    New end date/time in ISO 8601 format

    date-time

    packages?: PackageUpdate[]

    Package-specific updates for existing packages

    invoice_recipient?: BusinessEntity
    new_packages?: PackageRequest[]

    New packages to add to this media buy. Uses the same schema as create_media_buy packages. Sellers that support mid-flight package additions advertise add_packages in both valid_actions[] (deprecated) and as an entry in available_actions[] (authoritative). Sellers that do not support this MUST reject with ACTION_NOT_ALLOWED (preferred) or UNSUPPORTED_FEATURE (legacy).

    reporting_webhook?: ReportingWebhook
    push_notification_config?: PushNotificationConfig
    idempotency_key: string

    Client-generated idempotency key for safe retries. If an update fails without a response, resending with the same idempotency_key guarantees the update is applied at most once. MUST be unique per (seller, request) pair to prevent cross-seller correlation. Use a fresh UUID v4 for each request.

    16

    255

    ^[A-Za-z0-9_.:-]{16,255}$

    context?: ContextObject
    ext?: ExtensionObject