Requires audit logs to be enabled for your organization.
The audit logs record who changed what in your Flip organization, and when. Each entry names the person or system that made the change, the object that changed, and the values before and after. Use them to answer questions after the fact: who granted this person access, who changed this profile field, who created this API client.
This is the surface that security and compliance teams ask for in a vendor assessment. It is a read-only record; nothing in the audit logs can be edited or deleted from the Admin Console.
What is recorded
Audit logs cover the identity objects in your organization. Each object type carries its own set of recorded changes.
| Object | Examples of what is recorded |
|---|---|
| Users | Account created, updated, and deleted; locked and unlocked; password and passkey changes; successful sign-ins |
| User groups | Group created, archived, and restored; members added and removed; assignment rules created and changed |
| User attribute definitions | Profile field created, updated, and deleted |
| API clients | Client created and deleted; access token generated |
| OIDC clients | Client created, updated, and deleted; the client secret being viewed |
Reading an OIDC client secret is recorded as its own entry. Viewing a secret is a sensitive action, so it leaves a trace even though nothing changed.
Coverage differs by object. Not every operation on every object produces an entry yet. If your compliance process depends on a specific operation being recorded, confirm it in a test organization before you rely on it.
What an entry contains
- Actor. The account that made the change. Automated changes have the actor System: for example a group membership granted by an assignment rule, or a user created by provisioning. A System entry means no person triggered it directly.
- Action. Create, update, delete, or read.
- Object. The object that changed, and where relevant the sub-object, such as a credential or a group membership on a user.
- Timestamp.
- Before and after values. Open an entry to see the raw values from before and after the change. Not every entry has both: a sign-in has no previous state, so it carries only the new one.
Values are shown as raw technical data, close to how the system stores it, without renaming or translation. This keeps the record faithful to what actually happened rather than to a friendlier label. Do not build automated parsing on the exact field names and structure inside an entry.
Search the audit logs
- Open the audit logs in the Admin Console.
- Set the time range you want to review. You can query at most one month at a time. For a longer period, run several queries.
- Optionally filter by object type to narrow the list to users, user groups, attribute definitions, API clients, or OIDC clients.
- Select an entry to open it and see the actor, the object, and the before and after values.
You will know your filter worked when the list shows only entries of the type you selected within the range you set.
Retention
How far back you can search depends on whether Frontline Identity is enabled for your organization.
| Frontline Identity | Searchable history |
|---|---|
| Enabled | 1 year |
| Not enabled | 30 days |
The one-month limit per query applies inside that window. The retention window sets how far back you can go; the query limit sets how much you can read at once.
If your compliance requirements need a longer window than your organization has, contact your Customer Success Manager.
Read the audit logs through the API
The audit logs are also available through the Flip admin API, so you can pull entries into your own system, for example on a schedule into a SIEM or a data warehouse. The endpoint reference is at getflip.dev.
Flip does not push audit entries anywhere. There is no streaming feed and no webhook, so an integration polls the API rather than receiving events.
How audit logs differ from authentication events
The two pages answer different questions.
| Audit logs | Authentication events | |
|---|---|---|
| Answers | Who changed what | Who signed in, and how |
| Sign-in coverage | Successful sign-ins | Sign-in activity in more detail |
If you are investigating a change to an account or a permission, use the audit logs. If you are investigating sign-in behaviour for a specific person, start with authentication events.
Limits
- Permission is all or nothing. Access to the audit logs is granted for the whole organization. An admin who can see the audit logs sees every entry in them; there is no way to limit an admin to the users or groups they manage. Only System Admins can be granted this access.
- No alerting. The audit logs are a record you query, not a monitor that notifies you. Build alerting on your own side from the API.
- No export from the console. Downloading a filtered list from the Admin Console is not supported; use the API.