Overview

Partially update existing Onsite Display campaigns using field-level updates.

Unlike PUT requests, PATCH requests allow you to update only the fields you want to modify without resubmitting the entire campaign object.

PATCH is typically the preferred update method when only a subset of campaign attributes must change because it:

• Reduces payload size
• Minimizes the risk of overwriting existing values
• Simplifies operational updates
• Supports efficient batch updates

This endpoint supports both single-campaign and batch update workflows.

Availability

Supported for Onsite Display only.

When to use PATCH

PATCH is designed for incremental campaign updates.

How it works

PATCH updates are applied at the field level.

Only fields included in the request payload are updated. Existing values for omitted fields remain unchanged.

Key behaviors:

• Only included fields are updated
• Omitted fields remain unchanged
• Pass null to remove an existing value

Before you begin

• Valid advertiserId
• Valid campaignId
• Campaign in an eligible lifecycle state
• Existing campaign configuration reviewed before updating

Endpoint

PATCH /api/v1/campaigns

(View technical specifications)

Request details

How this request is used

Use PATCH requests to:

• Update campaign metadata
• Adjust budgets
• Adjust schedules
• Extend campaign duration
• Remove optional field values
• Perform lightweight operational updates

PATCH is recommended whenever only a subset of campaign attributes needs to change.

Campaign field update eligibility

Campaign lifecycle state determines which fields remain editable.

*Can only be updated if configured at the campaign level during campaign creation.

• ✅ = field can be updated
• ❌= field cannot be updated
• ⚠️= limited update support available
• extend endDate to edit if status = completed

Lifecycle considerations

As campaigns move through lifecycle states, update flexibility decreases.

Configuration inheritance rules

Budget, schedule, and delivery settings must remain configured at their original level.

The following fields always remain grouped together:

• budgetType
• dailyBudget
• totalBudget
• startDate
• endDate
• deliverySpeed

For a complete explanation, see Campaign vs Ad Group Configuration Rules.

Batch update behavior

This endpoint supports bulk updates.

Each campaign update is processed independently.

Batch requests:

• Are not transactional
• May partially succeed
• Return one result per campaign
• Support up to 10 campaign objects
• Requires a consistent advertiserId

See the Batch Requests Guide for retry strategies and partial success handling.

Sample requests

curl -X PATCH \ 'https://developer.api.us.stg.walmart.com/api-proxy/service/display/api/v1/api/v1/campaigns' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer <auth_token>'
--header 'WM_SEC.AUTH_SIGNATURE: **************' \ --header 'WM_SEC.KEY_VERSION: 1' \ --header 'WM_CONSUMER.ID: adfwe-v23-faasd2r-afs-asdfqeff' \ --header 'WM_CONSUMER.intimestamp: 1565309779' -data ' [        { "campaignId": 1, "advertiserId": 1, "name": "test-name"
}
]'

curl -X PATCH \ 'https://developer.api.us.stg.walmart.com/api-proxy/service/display/api/v1/api/v1/campaigns' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer <auth_token>'
--header 'WM_SEC.AUTH_SIGNATURE: **************' \ --header 'WM_SEC.KEY_VERSION: 1' \ --header 'WM_CONSUMER.ID: adfwe-v23-faasd2r-afs-asdfqeff' \ --header 'WM_CONSUMER.intimestamp: 1565309779' -data ' [        { "campaignId": 1, "advertiserId": 1, "description": null, "name": "test-name3"
}
]'

curl -X PATCH \ 'https://developer.api.us.stg.walmart.com/api-proxy/service/display/api/v1/api/v1/campaigns' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer <auth_token>'
--header 'WM_SEC.AUTH_SIGNATURE: **************' \ --header 'WM_SEC.KEY_VERSION: 1' \ --header 'WM_CONSUMER.ID: adfwe-v23-faasd2r-afs-asdfqeff' \ --header 'WM_CONSUMER.intimestamp: 1565309779' -data ' [      { "campaignId": 1, "advertiserId": 1, "name": "test-name1", "description": "test-description"
},
{ "campaignId": 2, "advertiserId": 1, "name": "test-name2", "description": "test-description", "objective": "awareness"
} ]'

Response details

What this response returns

The response confirms whether each campaign update succeeded or failed.

Batch operations return one response object per campaign.

Key fields to use

• campaignId
  Campaign associated with the result.

• code
  Overall update result (success, failure)

• details
  Validation messages, processing feedback, or failure reasons

How to interpret results

Successful updates

A successful response confirms the campaign was updated.

Batch updates

Batch requests may contain both successful and failed objects within the same response.

Always validate results at the individual campaign level.

Sample responses

[  { "code": "success", "details": ["string"], "campaignId": 1 }
]

[   { "code": "failure", "details": [ "string" ], "campaignId": 1,    "message": "string",
    "errors": [ { "field": "string", "errorType": "string", "description": "string" } ] },
{ "code": "success", "details": ["string"]    "campaignId": 2,    "message": "string",
    "errors": [ { "field": "string", "errorType": "string", "description": "string" } ]
 }
]

Common issues

• Attempting to move budget configuration from campaign level to ad group level
• Updating immutable fields after scheduling
• Sending mixed advertiser IDs in batch requests
• Using frontloaded pacing with daily budgets
• Forgetting to explicitly pass null when removing field values
• Attempting to update a completed campaign

What happens next

After updating campaigns:

1. Persist updated campaign metadata
2. Review validation messages
3. Retry failed campaigns individually if needed
4. Validate campaign lifecycle state
5. Continue downstream ad group workflows

Related pages

• Update Campaign Delivery Status
• Batch Requests
• Campaign vs Ad Group Configuration Rules
• Lifecycle States & Statuses
• Campaign Hierarchy
• Item Set Association