Skip to main content

Audit logs

Audit logs help Builders understand what changed in an app, who changed it, and when it happened.

Switera Audit Logs with labeled filters, export format selection, and expandable event rows
Use audit logs after setup changes, failed workflows, key rotation, or security-sensitive actions.

When to open audit logs​

Open Developer > Audit Logs when you need to answer:

  • who changed an Auth setting?
  • when was an API key rotated?
  • who created or edited an organization?
  • was a webhook endpoint changed?
  • did a setup action happen in the wrong app?
  • what changed before a user-visible issue started?

Filter activity​

Use filters to narrow the log:

FilterUse it for
Action or event typeFind one kind of change.
Actor IDFind changes by a specific Builder or system actor ID, not an email search.
Date fromStart an investigation window.
Date toEnd an investigation window.

Set a narrow time range first. Expand only if the expected event is not visible.

Select Apply to fetch matching events. Typing does not change the current results or export scope. Dates use your browser's local timezone, including the whole end date. Clear removes the applied filters and returns to page one.

Expand an event using the arrow next to its action to inspect full event, actor, and resource IDs, timestamp, IP address, and payload. The table scrolls independently and retains column headers. On mobile, scroll horizontally for the remaining columns. A failed read shows an error and Retry, not an empty log.

Export logs​

Choose CSV or JSON in Export format, then select Export. Exports use the currently applied filters, not unsaved filter edits.

Export only what you need. Audit logs can contain operational context and should be handled as internal operational data.

Investigation workflow​

  1. Open the affected app.
  2. Open Developer > Audit Logs.
  3. Filter by the approximate time window.
  4. Search for the affected area, such as Auth, email, webhook, organization, or key.
  5. Identify the actor and event.
  6. Compare the current setting with the expected setting.
  7. Revert the change if safe.
  8. Rotate credentials if a secret may have been exposed.

What not to put in public tickets​

Do not paste:

  • passwords
  • provider secrets
  • API secret keys
  • private tokens
  • full exported user lists
  • raw sensitive log payloads

Include only the minimum context needed for support or engineering review.

Related pages: