GitOps Commands

Use the GitOps endpoints when an administrator needs to inspect or explicitly reconcile selected hubs, clients, or ACLs.

Commit Flow

1. Call POST /v1/gitops/render-diff with one or more resource references.
2. Review the returned manifests and diff.
3. Call POST /v1/gitops/commit with the same references, a message, and an Idempotency-Key header.
4. Read operation from the response and poll its links.self URL.
5. Stop when the operation reaches committed, failed, or timed_out.

curl --fail-with-body \
  -X POST \
  -H "Authorization: Bearer $THALOVANT_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: gitops-sync-20260711-001" \
  https://api.thalovant.com/v1/gitops/commit \
  -d '{"message":"Reconcile selected hub","resources":[{"type":"hub","id":"HUB_ID"}]}'

The API stores the operation and Git work item before responding. Git rendering, cleanup, commit, and push happen in the durable worker. Owner-scoped cleanup does not remove another tenant’s manifests, another resource type, or unannotated legacy paths.

Compatibility Envelope

POST /v1/gitops/commit keeps the existing HTTP 200 response and legacy fields during the /api/v1 migration window. New clients use the additive operation field and Location header. On initial acceptance, commit_sha is null, created is false, and manifests is empty because the worker has not run yet.

Note

An operation can finish with committed and a null git_commit_sha when the repository already matches the desired state. Check details.git_commit_created to distinguish a new commit from a no-change reconciliation.

See Operations for polling and failure handling.