Sitecore Marketer MCP a deep dive - Agent API Jobs - Part 3
Now that we understand how to authenticate and interact with the Agent API, let’s consider a practical scenario.
Imagine that some content has been added or updated in a connected Sitecore instance, and those changes unexpectedly cause an issue on the website. In such situations, the natural solution is to roll back the changes.
Typically, the usual approach is to navigate to the Sitecore Content Editor, locate the affected item, and manually restore the previous content. This works well if we have a backup of the earlier content. However, if no backup exists, reverting the changes becomes more complicated. We may need to inspect item versions, review previous changes, or use other manual recovery approaches, which can be both time-consuming and error-prone.
This is where the Job API becomes extremely useful.
The Job API allows us to execute operations that can restore or roll back the system to a previous state, helping developers recover from unintended content updates more efficiently.
It is also important to understand that the Job API is not available as a tool within the Sitecore Marketer MCP. The Marketer MCP server is primarily designed for marketers, providing them with tools focused on marketing workflows and content operations.
For developers who require deeper control over agentic applications, the Agent API (including the Job API) provides the flexibility needed to perform advanced tasks such as rollback operations, automation workflows, and other system-level actions.
In the following sections, we will explore how the Job API works and how developers can use it to manage and execute background operations effectively.
Consider this scenario, in which I used the Agent API to update fields on several existing items and also added components to a few pages. In total, I performed around five to six operations on the Sitecore instance using the Agent API.
Now imagine that after performing these operations, I need to roll back the Sitecore instance to its original state, before any of these Agent API calls were executed.
This can quickly become challenging. Since multiple operations were performed, such as creating content, updating fields, and adding components, it can be difficult to track exactly what was changed. Without a clear record of these actions, manually rolling back the changes would be complex and time-consuming.
This is where Jobs become extremely useful.
When making Agent API requests, we can include a special request header called x-sc-job-id. This header allows us to assign a unique identifier to a set of operations. Any value can be passed in this header.
Once this header is included in the request, all Agent API mutation operations performed with that header value are grouped and tracked under the same Job ID. This makes it easier to identify and manage related changes.
In the example shown in the screenshot above, we used the header value job007.
All the Agent API requests that were executed with the header x-sc-job-id: job007 are grouped together under the same job. This allows us to retrieve and review all operations associated with that job ID, making it significantly easier to manage or roll back the changes if needed.
Now, let’s retrieve all the operations that were performed using the job id job007.
Comments
Post a Comment