Admin API

The admin namespace exposes bounded maintenance jobs meant to be driven by a cron or queue rather than a UI. These methods live on the system namespace at cms.api.admin.<method> and mirror on the client as client.admin.<method> with identical types. Every method requires the admin permission resource, so gate the trigger accordingly.

runPruning and runScheduled each do one capped pass and report progress, so a plain cron can ping them periodically while a queue driver re-enqueues until the work drains. None of these methods produces a commit envelope.

Run a Pruning Pass

Run one bounded, resumable pruning pass to reclaim storage: it deletes old commits, hard-deletes archived entries (roots), and frees unreferenced assets. Each call does one capped pass within its time and root-count budgets and persists its own progress, so you keep calling it (or let a cron ping it) until done is true. Throws DATA_RETENTION_NOT_CONFIGURED when data retention is not configured.

const data = await cms.api.admin.runPruning({
  body: {
    maxRoots: 10,
    maxDurationMs: 5000,
  },
});

const { data, error } = await client.admin.runPruning({
  body: {
    maxRoots: 10,
    maxDurationMs: 5000,
  },
});

done is true when the pass drained all currently-due work (stopped idle); stoppedReason is one of 'maxRoots', 'budget', or 'idle'.

Process Scheduled Publishing

Drain the scheduled-publishing queue: every due row (scheduledAt <= now and not yet processed) is published or unpublished with the same machinery as the single publish endpoints, then stamped processed. A row whose publish or unpublish fails is still marked processed and surfaced in failed, so a permanently broken intent never re-runs forever.

const data = await cms.api.admin.runScheduled({
  body: {
    limit: 50,
  },
});

const { data, error } = await client.admin.runScheduled({
  body: {
    limit: 50,
  },
});

failed is an array of { id, rootId, branchId, action, error }, one entry per row whose publish or unpublish threw.

Rebuild the Search Index

Rebuild the entire full-text search index from scratch, re-indexing every root, comment, merge request, variable, template, asset, and notification. Reach for this after a bulk import or an index-shape change; it takes no input and hands back the per-type counts it wrote.

const data = await cms.api.admin.reindexSearch();

const { data, error } = await client.admin.reindexSearch();

indexed is a record of per-entity-type counts that were re-indexed.