An audit log is an immutable, append-only record of every create, update, or delete mutation performed on org resources. Each entry captures the durable actor identity — a user or service account — and the credential used for the request, preserving attribution even after a key is revoked.

The model

Each audit log entry has:

  • actioncreate, update, or delete: the mutation kind.
  • resource_type / resource_id / resource_name — identifies the affected resource. Example resource types include job, channel, and document.
  • actor_type / actor_id — the durable identity that performed the action.
  • credential_id — the API key or token used for the request, recorded even if the credential is later revoked.
  • user_id — set when the actor is a human user.
  • project_id — set when the affected resource belongs to a project.
  • changes — a before/after snapshot of field values for update actions.
  • status / error_type / error_message — outcome of the mutation and, on failure, the reason.
  • ip_address / user_agent — request metadata for the originating call.
  • created_at — timestamp when the action was performed.

Auditing a service account's recent writes

The listAuditLogs endpoint accepts query parameters to filter by actor, resource type, and time window:

curl -G "$MOBIUS_API_URL/v1/audit-logs" \
  -H "Authorization: Bearer $MOBIUS_API_KEY" \
  --data-urlencode "actor_id=svc_worker-01" \
  --data-urlencode "resource_type=job" \
  --data-urlencode "created_after=2026-04-01T00:00:00Z" \
  --data-urlencode "created_before=2026-05-01T00:00:00Z"

Each page of results includes the action, resource_id, changes for update entries, and the credential_id — even if that credential has since been revoked. Iterate using the next_cursor value until has_more is false.

Where you see it

  • API — the Audit Logs tag. Combine actor_id and resource_type to scope results to a specific identity and resource class. Pass created_after and created_before for time-bounded compliance exports.

See also

  • Triggers — event rules that start workflow runs.
  • Workflows — the workflow execution model.
  • Runs — individual workflow executions.