Amen Data Boundaries

Amen products do not duplicate platform data in every product database. Identity owns authentication, Core owns churches and memberships, and each product owns only its domain.

Verify the product session

The browser first authenticates with Identity. Core then mints a short-lived token for the installed product and selected church. The product API verifies that token and derives the workspace and user identifiers from its claims.

const principal = await productSessionVerifier.verify(request);

await projectRepository.list({
  workspaceId: principal.workspaceId,
  userId: principal.userId,
});

Tenant identifiers supplied by a URL or JSON body are never trusted as authorization.

Keep product records tenant scoped

Every product-owned table carries workspaceId; every unique constraint and lookup includes that boundary. The repository requires a verified tenant context rather than accepting a raw global database client.

await productContext.withWorkspace(principal.workspaceId, async (repository) => {
  await repository.createProject({ name: "Parish renewal" });
});

Call platform capabilities through their owner

• profiles, login and recovery go to Identity;
• churches, members, roles, files, plans and billing go to Core;
• B2B projects stay in the B2B service;
• email, outbound webhooks and analytics use their documented Amen contracts.

If a contract does not exist yet, preserve the user-facing surface as unavailable and record the missing service. Do not introduce a second user, member, subscription or API-key model in the product database.

Practical checks

• Keep service tokens audience restricted and in memory in the browser.
• Apply tenant isolation in both HTTP authorization and database access.
• Make writes idempotent when retries can cross a service boundary.
• Return provider-neutral DTOs from Core rather than leaking Stripe or storage credentials.
• Test that cross-tenant identifiers behave as not found.