Sync Auth0 Data to FGA

note

Auth0 Relationship Sync is currently in Beta, available to a limited set of customers, and not yet recommended for production use.

Auth0 Relationship Sync automatically keeps your Auth0 tenant and your FGA store in sync. When users, organizations, roles, or group memberships change in Auth0, those changes are translated into FGA relationship tuples in near real-time, without any custom pipeline code.

When to use

Use Auth0 Relationship Sync when:

• You manage users, organizations, and roles in Auth0 and want to enforce fine-grained authorization in FGA without building and operating a custom event pipeline.
• You need near real-time consistency: for example, when a user is removed from an organization or a role is revoked, their FGA permissions should update within seconds.
• You want guaranteed, in-order event delivery with automatic retry and resume, rather than relying on fire-and-forget webhooks.

How it works

FGA is connected to Auth0 via a client to consume the Events API, a pull-based, cursor-driven stream distinct from push-based Event Streams. When users, organizations, and roles change in Auth0, events are emitted, and these events flow to a Sync pipeline.

Customers define mapping rules to process these events and write or delete tuples in the FGA store, validating them directly in the FGA Dashboard before activating the Sync pipeline; see Validating a mapping file.

What data can you sync

Before writing a mapping file, it helps to know which Auth0 entities Relationship Sync can turn into FGA tuples today.

Entity	What syncs	Notes
Users	Creation, updates, deletion	Includes user_metadata and app_metadata: any field on the event payload can drive a mapping rule, not just identity fields.
Organizations	Creation, updates, deletion
Organization membership	Members added to or removed from an organization
Tenant roles	A role assigned to or removed from a user within an organization membership	Covers assigning member roles that come from the tenant-wide role catalog; Auth0 calls these "Tenant roles" there, as distinct from "Organization roles." Organization roles (in Early Access) are out of scope, since that's a separate, per-organization role catalog with no corresponding event yet, so it can't be synced regardless of stage. The linked doc above covers both.
SCIM groups	Creation, updates, deletion
SCIM group membership	Members added to or removed from a group, including nested groups

If you provision users and groups from an upstream identity provider into Auth0 via inbound SCIM, those entities sync the same way as natively-created ones; see Auth0's Configure inbound SCIM doc.

Supported Auth0 events

Category	Events
Users	user.created, user.updated, user.deleted
Organizations	organization.created, organization.updated, organization.deleted
Organization Membership	organization.member.added, organization.member.deleted
Tenant Role Assignments	organization.member.role.assigned, organization.member.role.deleted: covers assigning a tenant role to a user within an organization membership only; there's no event for tenant-level role assignment outside an organization context
SCIM Groups	group.created, group.updated, group.deleted
SCIM Group Membership	group.member.added, group.member.deleted

See the Auth0 events catalog for the full list of events and their payload shapes.

Known limitations:

• Currently, creating, updating or deleting roles from an Auth0 tenant does not trigger any events. Deletion is the most consequential gap: if a role is deleted while still assigned to users, the corresponding FGA tuples go stale with no event to react to. Avoid deleting roles that are in active use, or clean up FGA tuples manually before deleting the role in Auth0.

• Assigning a role at the tenant level, outside any organization, does not trigger any events. Auth0 emits organization.member.role.assigned/.deleted only for a role assigned to a user within an organization. Since there's no event for this path, none of your role assignments should rely on it if you want them reflected in FGA: keep tenant-level role assignment scoped to within an organization membership.

• Removing a user from an organization doesn't clean up their assigned roles within the organization, by itself. organization.member.deleted fires when a user leaves an organization, or when the organization itself is deleted, but organization.member.role.deleted does not, in either case, and the payload never includes which roles the user held. A role-assignment tuple can outlive the membership it was granted under unless your mapping accounts for this. If your model writes roles as relations on the organization itself, see Cleaning up roles on membership removal for a mapping rule that covers this. The comprehensive template writes roles to a separate, tenant-wide role:{id} object instead, which that technique can't reach directly; it wires role assignments through an intermediate organization_membership object so a single delete on membership removal revokes every role tied to it, without needing to know which roles the user held. See the note under that template.

• group.deleted does not cascade. When a group is deleted, Auth0 emits only the single group.deleted event; it does not fan out per-member removal events. Your mapping must explicitly clean up all group-related tuples in the group.deleted rule using a full-delete tuple_filters entry; see Cleaning up group tuples on group deletion (the comprehensive template leaves this rule out to avoid duplicating that example).

• organization.deleted cascades membership, but not directly roles. When an organization is deleted, Auth0 does emit organization.member.deleted for every member, so member tuples clean up through that event, the same one covered above. It does not emit organization.member.role.deleted, the same gap as above — but since that event is what your "Remove user from organization" rule already handles, no separate cleanup rule is needed for organization.deleted itself; the per-member cascade covers it.

• Duplicate role assignments. Assigning a role to a user who already has it re-fires organization.member.role.assigned, unchanged. This is safe: every write a Sync pipeline performs ignores conflicts rather than failing (see Idempotent writes and deletes), but don't assume the event only fires once per assignment.

Next: Getting Started with Auth0 Relationship Sync to set up your first Sync pipeline, or Writing a Mapping File for ready-to-use mapping templates covering everything in the tables above.