Use audit history for social operations
Retain who changed, approved, published, retried, or replied to customer-facing content.
Treat the audit log as an immutable record of actor, action, resource, request ID, time, and safe metadata. Use it to explain workflow transitions without storing provider tokens, API keys, message secrets, or raw sensitive payloads.
What this means in practice
Treat the audit log as an immutable record of actor, action, resource, request ID, time, and safe metadata. Use it to explain workflow transitions without storing provider tokens, API keys, message secrets, or raw sensitive payloads.
Use the documented brand and account boundaries consistently across the scheduler, REST API, SDK, MCP tools, SSE consumers, and webhooks. That makes the same social operation explainable to an operator and reproducible by an integration.
Implementation checklist
Record human and service actors distinctly.
Attach request IDs to mutations and downstream attempts.
Include revision and target identifiers when an action affects only part of a post.
Sanitize metadata before persistence and export.
Provide brand-scoped audit access only to roles that need it.
Operational details
Webhook delivery history and post attempt history complement the audit log rather than replacing it.
An approval record should identify the exact revision approved.
Credential status can be audited without recording secret values.
Common mistakes to avoid
- Do not log bearer tokens, provider refresh tokens, webhook secrets, or raw API keys.
- Do not overwrite an earlier action when the resource state changes later.
- Do not let cross-brand audit searches bypass tenant isolation.