Let customers inspect and export their own history
Customers can read, filter and export their audit records through the application’s resource interface. The same declared contract supplies the standard screens, access rules and API reference.
The audit surface offers inspection, not editing: customer operations cannot rewrite or delete its records.
Example — Let customers inspect their own trail
A customer administrator filters a role change by person and date, then exports the matching window for the security team.
For engineers
The organization route selects the customer scope. READ, LIST and structured SEARCH expose the declared filters; exportAuditLogs returns a bounded synchronous JSON result. The export body cannot choose a different organization.
Its actual request contract is:
Selected source from audit-logs.shared.resources-config.schemas.ts:
export const AuditLogs_ExportRequestDto = z.object({
eventType: z.string().optional(),
eventCategory: z.enum(AuditEventCategory).optional(),
severity: z.enum(AuditEventSeverity).optional(),
userId: z.string().optional(),
createdAt: Resources_Filter_DateRangeSchema.optional(),
// This is a bounded, synchronous API response, not an archive job. Keep its
// ceiling aligned with the resource LIST operation so callers cannot request
// a window that the repository will silently truncate.
// Input stays optional and the backend applies 100 when omitted. Record the
// default as metadata rather than a Zod output default, which would falsely
// make the request field required in JSON Schema.
maxRecords: z.number().int().min(1).max(100).optional().meta({ default: 100 }),
}).strict();
For example, submit { "severity": "warning", "maxRecords": 50 } to the generated collection export operation. The response contains records, format: "json" and totalCount. The default and ceiling are 100 records; larger requests are rejected. This is a selected result window, not an archive of all matching history.
Follow the appropriate viewing authority
Organization access is role-gated and confined to that organization’s records. Application-level audit viewing has its own super-administrator resource and admission requirements; it can include events without a selected organization and observes cross-tenant reads.
The same store supports those distinct doors. Keep scope selection in the authenticated operation, and use the generated reference for the exact deployed route rather than constructing an unscoped query against the collection. Repository-only creation is reserved for framework emitters; customer update and deletion are absent.
Separate viewing from exporting
| Operation | Declared role access | Scope |
|---|---|---|
| READ, LIST and SEARCH | Organization member, organization administrator and superadministrator | The authorized organization context |
exportAuditLogs | Organization administrator and superadministrator | A bounded export within the authorized organization context |
These are the resource’s declared operation roles. They do not authorize choosing an arbitrary tenant or replacing the caller’s scope. Application-wide assurance review uses its separately admitted surface.