Authdog

Observability guide

Audit Logs

Authdog audit logs expose environment identity activity and organization-level administrative changes for investigation and monitoring. This guide covers interactive triage in the console and controlled retrieval over the verified REST routes.

Prerequisites

  • Tenant, project, and environment identifiers for the system being investigated.
  • Console access to Audit.
  • For REST retrieval, a server-held Authdog API token with only the required scope.
  • A UTC incident window, a known user or external ID, and an expected event category where possible.
  • An approved evidence destination with encryption, access control, and its own retention policy.

Implementation

  1. Select the correct scope. Choose the intended tenant, project, and environment before opening Audit. An empty result in one environment doesn't prove no event occurred in another.

  2. Start with a narrow query. Filter a short UTC time range using a known user, event type, or external ID. Expand only after confirming timestamps and timezone assumptions.

  3. Use the overview and event feed. Overview shows volume and categories; the event feed shows individual records. Saved filters can preserve recurring combinations.

  4. Discover types instead of guessing. The event-types explorer groups observed and catalog-backed types with counts and samples. Use a real sample before building parsing or alerting rules.

  5. Retrieve environment records when automation is required.

    curl --get \
  "https://api.authdog.com/v1/tenants/$TENANT_ID/environments/$ENVIRONMENT_ID/audit/logs" \
  -H "Authorization: Bearer $AUTHDOG_API_TOKEN" \
  --data-urlencode "startDateTime=2026-07-01T00:00:00Z" \
  --data-urlencode "endDateTime=2026-07-02T00:00:00Z" \
  --data-urlencode "eventTypes=SIGNIN_SUCCESS,MFA_SIGNIN_FAILURE" \
  --data-urlencode "limit=100"

    Pagination uses numeric offset and limit (max 500).

  6. Inspect the catalog for the environment. GET /v1/tenants/{tenantId}/environments/{environmentId}/audit/event-types/catalog returns event/category pairs, build filters from returned values rather than a hard-coded list.

  7. Retrieve organization administration records separately. GET /v1/organizations/{organizationId}/audit/logs covers organization-level records; keep it conceptually separate from environment identity activity.

  8. Build the incident timeline. Record event ID, UTC timestamp, actor, IP, and organization context for each relevant event, then correlate adjacent activity. Preserve raw payloads before remediation.

Security considerations

  • Keep API tokens server-side, out of browser code, shared shell history, and logs.
  • Parse eventPayload defensively, it's source-specific and can add fields over time; never make an authorization decision from audit data.
  • Authdog exposes recorded data but makes no fixed retention or compliance guarantee, forward verified events to a destination you govern if you need a controlled archive.

Validation checklist

  • Query uses the intended tenant, environment, organization, and UTC range.
  • A known test sign-in or administrative action appears in the console.
  • Event type comes from the catalog or an observed record.
  • REST totals and pagination produce no unintended gaps or duplicates.
  • Parser tolerates null fields and unknown keys.
  • Export destination restricts access and applies your retention policy.

Troubleshooting

For no results, verify environment and timezone first, then remove filters one at a time. For pagination gaps, keep filters and sort assumptions stable while changing offset, and don't exceed the 500-record limit. If organization changes are missing from the environment feed, query the organization audit route instead.

Next steps