Created: 12 Dec 2025, last update: 13 Dec 2025
Exploring the SitecoreAI Agent API Jobs Feature
Introduction
The SitecoreAI Agent API includes a jobs feature. The idea is simple, you can track all operations of a job and even revert a job to undo changes made by an AI agent or by any other application, such as a marketplace app or API-based automation. It sounds useful, but the documentation leaves many questions. It mentions an HTTP header called x-sc-job-id and says it is used to trace, audit, and revert actions. It does not say if the header is required, how it behaves, or how long a job exists.
When I looked at my conversations with the Sitecore MCP server, I could not find any jobId at all. The MCP server documentation is good, but it still raised important questions. Because of that I started testing the feature in detail.
Next to the MCP server, I also wanted to understand how to use the Jobs API in SitecoreCommander, because that is the tool I use for most automation and API testing. SitecoreCommander is designed to work with the Sitecore APIs and is a practical way to script, test, and run many calls in one place. It is especially useful when you want to work with the Agent API, Authoring API, Edge API, ItemService, or even WordPress XML imports.
These were my main questions:
• Does the MCP server use a jobId at all
• Can you reuse the same jobId for multiple operations or must it be unique
• Is a jobId created for you if you do not send one
• How does revert work, does it record field changes, or complete versions, and what happens when other users also update the same item
• How long does a job live
• Can you reuse a jobId in a different session with a different login
• Is it safe for larger batches of updates
Below are the answers based on real tests and not on theory see SitecoreCommander
Jobs and the Sitecore MCP server
Right now the MCP server exposes 42 tools and none of them use job features. If an item is removed the MCP server cannot restore it with a job, you can do it outside the MCP server with the archive. If an update is wrong you can sometimes fix it when the old value is still in the context, but there is no real rollback. Unless you use versioning. You can create a new version in an update by setting createNewVersion to true, but the MCP server does not do that by default. This was also my first clue. If a content update with a jobId always creates a new version it means the MCP server itself is not using job features in the background. At first I thought this was a bug. createNewVersion did not seem to work. But with the whole job flow in mind it makes sense. A job needs versions to revert, so the API forces a new version when you send a jobId.
Does the jobId need to be unique
You can reuse the same jobId for multiple operations. All operations are stored in that job in the order they happened. This is useful because you can revert the entire batch in one step. So a jobId is more like a transaction or a batch identifier.
Do you receive a jobId if you do not send one
No. If you do not send a jobId the system does not generate one. The change simply happens without any job tracking.
How revert works
A job stores references to the item versions that were created during the job. If the operation is a delete it stores a reference to the archive entry. When you revert a job the API goes through the operations in reverse order and undoes each one. It uses normal Sitecore versioning and the archive to do this. This has important consequences. If other users make changes outside your job those changes stay. For example, you update an item and version two is created. Another user creates version three. When you revert your job the system removes version two. Version three stays untouched. The same applies to edits. If version two is edited later, those edits are removed too because the revert simply removes the entire version.
How long a job exists
From my tests a job stays alive for one or two days. After that it is cleaned up. I could not find any job data in the Sitecore database, not spent many time on that because SitecoreAI runs in the cloud and we no longer have direct access to SQL to inspect what happens behind the scenes. My guess is that job data is stored outside the Sitecore database.
Can I reuse a jobId in another session or login
Yes. As long as the token belongs to the same environment you can work with the same jobId. A token from a different environment cannot access it. This is also logical because a job is always bound to a specific environment.
Are jobs safe for larger batches
Yes. I tested a batch of 432 updates. A full rollback took a little over a minute. The API returned a gateway timeout after one minute but the job continued in the background and finished successfully. You can follow the progress with the List Job Operations endpoint. A second test with around 1350 items also worked well. The updates took about 14 minutes and the rollback took around 4 minutes.
Example List job operations
[
{
"id": "6737e2a8-64c9-474e-bb52-a42fae85a386",
"type": "op",
"tenantId": "00ba8283-36b5-47aa-b100-07dc323bd2b6",
"jobId": "commander-job-xxx-updateitem-jbltest",
"sequenceNumber": 2,
"timestamp": "2025-12-11T18:39:52.488500",
"operation": "update_content_item",
"effectType": "VersionWrite",
"item": {
"id": "ede44817-4c9b-4fd2-bbc2-e8410c430bdd",
"version": {
"before": null,
"after": "2"
},
"language": "en",
"archiveId": null
},
"status": "succeeded",
"revert": null
},
{
"id": "fa954f55-7eb7-45e7-8597-bbc4b39a38d5",
"type": "op",
"tenantId": "00ba8283-36b5-47aa-b100-07dc323bd2b6",
"jobId": "commander-job-xxx-updateitem-jbltest",
"sequenceNumber": 1,
"timestamp": "2025-12-11T18:39:23.370733",
"operation": "update_content_item",
"effectType": "VersionWrite",
"item": {
"id": "a5507100-769e-4287-bcb7-271feb7540c0",
"version": {
"before": null,
"after": "2"
},
"language": "en",
"archiveId": null
},
"status": "succeeded",
"revert": null
}
]
Example Retrieves the details of a specific job
{
"id": "job-00ba8294-34b5-48ee-a311-08dc323bd2b0-commander-job-0-14b3dbb932b9483299c4e961319d5a88",
"status": "reverted",
"tenantId": "00ba8283-36b5-47aa-b100-07dc323bd2b6",
"jobId": "commander-job-0-14b3dbb932b9483299c4e961319d5a88",
"createdAt": "2025-12-12T08:51:40.781564",
"type": "job",
"lastSequenceNumber": 432,
"revert": {
"status": "succeeded",
"at": "2025-12-12T08:57:55.394891",
"error": null
}
}
Tip: The Sitecore Agent API does not provide a way to retrieve a lost jobId. If you don’t save it when starting a job, you won’t be able to check its status or undo it later. SitecoreCommander automatically logs every jobId so you can always find it
Observations on GET API Calls and Job IDs
It is noteworthy that even GET API calls have a jobId, like the Retrieve a content item by ID, despite not performing any mutations. These GET calls also appear in the job operations list. What exactly this means in practice is not entirely clear yet. It could be related to auditing or tracing, but further testing is needed to understand how these read-only operations interact with the job system and whether they can be affect jobs.
Closing Thoughts
Working with the jobs feature gave me a much clearer idea of what the Jobs API can and cannot do. I added a few JSON examples to show the behavior in practice. If you want C# versions of the same calls, you can find them in SitecoreCommander. I hope this helps you get productive faster and avoid some of the surprises I ran into.
