Revert
Undoes the change this job applied, where the application it was applied to supports undoing it. Check revert.available on the job first: whether a change can be undone depends on that application and on how long ago the change was made. Reverting creates a new job, returned here, which reports the undo’s own progress and per-target results; the original job records that it was reverted and points at this one. A revert cannot itself be reverted. Send an Idempotency-Key so a retried request does not revert twice. Requires the https://devx.{environment}.oleria.io/write scope.
Authorizations
OAuth 2.0 client-credentials flow. Request an access token from the token endpoint and send it as Authorization: Bearer <token>.
Headers
Unique key for this request, generated by the caller. Resending the same request with the same key returns the job the first one created instead of submitting a second one; sending a different request with a key already used is refused with 409, so a key accidentally reused across targets cannot silently skip them. Use one key per request, not one per batch. Recommended on every write: these operations change systems outside Oleria, so a client that times out and retries without one can apply the change twice. This matters even for the operations that are safe to repeat: asserting a membership that already exists grants nothing a second time, but without a key it is still a second job, with its own audit record and its own results.
Path Parameters
Id of the job, as returned by the write that created it.
Response
The change was accepted and is being applied. Poll the returned job for its outcome.

