Consuming Fabric

Fabric is the canonical source of truth for identity, tenancy, and authorization. All services must defer to Fabric for permission decisions, tenant state, and canonical IDs.

Frontend Usage

Use Fabric as the canonical source for:

• Organizations
• Teams
• Memberships
• Invitations
• Effective permissions

Recommended Pattern

1. Authenticate user (JWT or API key)
2. Fetch GET /v1/me to get the current principal
3. Fetch memberships, orgs, and teams
4. Fetch effective permissions for the active context
5. Cache only for UX convenience
6. Never trust frontend-only authorization

TypeScript

import { FabricClient } from "@fabric-platform/sdk";

const fabric = new FabricClient({ apiKey: "fab_xxx" });

// Get current user
const me = await fabric.getMe();

// Get their organizations
const orgs = await fabric.getMyOrganizations();

// Check a permission
const result = await fabric.checkPermission({
  resourceType: "organization",
  resourceId: orgId,
  action: "read",
});

Python

from fabric_platform import FabricClient

fabric = FabricClient(api_key="fab_xxx")

# Get current user
me = fabric.get_me()

# Get their organizations
orgs = fabric.get_my_organizations()

# Check a permission
result = fabric.check_permission(
    resource_type="organization",
    resource_id=org_id,
    action="read",
)

Rust

use fabric_sdk::FabricClient;

let client = FabricClient::new("http://localhost:3001", api_key)?;

// Get current user
let me = client.get_me().await?;

// Get their organizations
let orgs = client.get_my_organizations().await?;

// Check a permission
let result = client.check_permission("organization", &org_id, "read").await?;

curl

# Get current user
curl -H 'Authorization: Bearer fab_xxx' \
  http://localhost:3001/v1/me

# Get their organizations
curl -H 'Authorization: Bearer fab_xxx' \
  http://localhost:3001/v1/me/organizations

# Check a permission
curl -X POST http://localhost:3001/v1/authz/check \
  -H 'Authorization: Bearer fab_xxx' \
  -H 'content-type: application/json' \
  -d '{"resource_type":"organization","resource_id":"<org-id>","action":"read"}'

Backend Usage

Backend services should:

• Call Fabric for authz checks or embed a trusted decision token
• Use Fabric org/team IDs as canonical
• Avoid duplicating org/team/role truth
• Use API keys or service account tokens for service-to-service calls

TypeScript

// Check permission before a sensitive action
const allowed = await fabric.checkPermission({
  action: "organization.invite",
});
if (!allowed) throw new Error("Forbidden");

Python

# Check permission before a sensitive action
allowed = fabric.check_permission(action="organization.invite")
if not allowed:
    raise PermissionError("Forbidden")

Rust

// Check permission before a sensitive action
let allowed = client.check_permission_action("organization.invite").await?;
if !allowed { return Err("Forbidden".into()); }

curl

# Check permission before a sensitive action
curl -X POST http://localhost:3001/v1/authz/check \
  -H 'Authorization: Bearer fab_your_api_key' \
  -H 'content-type: application/json' \
  -d '{"action":"organization.invite"}'

Response Envelope

Every Fabric response conforms to a consistent envelope structure:

Field	Description
meta	request_id, trace_id, timestamp, status, version
context	principal_id, organization_id, team_id
data	The response payload
error	Error details (if applicable)
links	Pagination and related resource links

This applies uniformly across REST, SSE, WebSockets, and webhooks.

SSE payloads emit serialized envelope JSON in the data field of the event.