Base44 audit log: how to see who logged in and who changed what

Do you need an audit log at all?

If the app holds nothing sensitive and a handful of people use it, probably not. You need one when someone can ask “who changed this order?” or “who exported the customer list?” and the answer matters: money, staff data, customers, or an IT team that has to approve the app. Questions like these come up in most security reviews, and they are on the checklist IT runs before approving a Base44 app.

Base44 holds SOC 2 Type II certification for the platform. That covers how Base44 runs its service. It does not record what the people using your app do inside it.

A log you build in the app

On a plan without the Audit Logs API, the usual route is an entity that the app writes to. Ask the Base44 chat for it in one message:

Create an entity called AuditLog with the fields user_email (text), action (text), detail (text) and at (date-time). Any signed-in user can create a record, but only admins can read, edit or delete records. Add a function logEvent(action, detail) that reads the signed-in user and creates an AuditLog record, and call it when someone opens the app and each time someone creates, edits or deletes a record.

The function it writes should look like this (adjust the import to your app):

import { base44 } from "@/api/base44Client";

export async function logEvent(action, detail = {}) {
  const user = await base44.auth.me();
  await base44.entities.AuditLog.create({
    user_email: user.email,
    action,                       // "open_app", "delete_order", "export_customers"
    detail: JSON.stringify(detail),
    at: new Date().toISOString()
  });
}

Then open the entity’s settings and check that the access rules really are “anyone signed in can create, only admins can read or change”. Keep44 has not tested this exact prompt, so confirm the rules were applied before you trust the log.

Where a self-made log falls short

• It records only what the code calls. A screen or action you forgot leaves a gap.
• No real sign-in events. A request on Base44’s feedback board asks for login and logout events and suggests writing a record on page load as a workaround. That records “opened the app”, not a verified sign-in.
• Editors can change the code that writes the log. Anyone with edit access to the app can remove a logEvent call, so the log proves less than one the platform keeps for you.
• Retention and export are yours. Export the table to CSV on a schedule and decide how long to keep it. The log holds email addresses, which are personal data.

On Enterprise, the Audit Logs API returns authentication events, entity changes and administrative actions for every app in the workspace, and can feed a SIEM. Callers need the admin or owner role and a workspace API key. The Audit Logs docs do not state how long events are kept.

When the app runs on the company server

In the hybrid model the app runs on the client’s servers and the client keeps building it in Base44. The log then lives in a SQL Server table that IT already backs up, and database permissions decide who can read it. The app should be able to insert rows but not edit or delete them. Company sign-in through Entra ID adds Entra’s own sign-in records, which the app’s editors cannot touch. How that works is in the guides to Base44 SSO with Microsoft Entra ID and to running a Base44 app on-premise.

On the client’s servers, the log sits in the database and backup plan IT already runs.

When Keep44 isn’t the answer: if your workspace already has an Enterprise plan, use the Audit Logs API. If the app is small and holds nothing sensitive, the entity above is enough on its own.

Sources

• Base44: Audit Logs API overview (Enterprise workspace, workspace API key, event types). Accessed 10/22/2026.
• Base44: Security overview (each app’s security belongs to its builder). Accessed 10/8/2026.
• Base44: Privacy and security (SOC 2 Type II for the platform). Accessed 10/21/2026.
• Base44 feedback board: auth event webhooks (request for login and logout events). Accessed 10/21/2026.