Skip to main content

Multi-Tenancy (API)

Console enforces multi-tenancy through JWT tokens and automatic data filtering.

Tenant Context in JWT​

Every JWT token contains the company_id, which identifies the tenant (customer organization):

{
  "sub": "user_id",
  "user_id": "507f1f77bcf86cd799439011",
  "company_id": "507f1f77bcf86cd799439012",
  "email": "[email protected]",
  "is_owner": false,
  "token_type": "access"
}

Data Isolation​

All API requests automatically filter by company_id from the JWT:

// You request:
GET /v1/users

// API internally queries:
db.users.find({ company_id: jwt.company_id })

You cannot access data from other companies, even with valid IDs.

Cross-Company Protection​

If you try to access a resource from another company:

GET /v1/users/507f1f77bcf86cd799439099
# User belongs to company_id: XXXXXXX

# Response: 404 Not Found
# (Even though the user exists, it's not in your company)

This applies to all resources:

  • Users
  • Groups
  • Permissions
  • Settings
  • Any company-scoped data

How It Works​

  1. Authentication: User logs in with company slug and credentials
  2. JWT Generation: API creates JWT with company_id
  3. Request Processing: Every API call includes JWT in Authorization header
  4. Automatic Filtering: API middleware extracts company_id and filters all queries
  5. Isolation Enforced: Users can only see and modify their company's data

Best Practices​

1. Always Include Authorization Header​

curl -H "Authorization: Bearer <your_jwt_token>" \
  https://api.console.solucao42.com.br/v1/users

2. Don't Hardcode Company IDs​

The company_id is automatically extracted from the JWT. Never try to override it in your requests.

// ❌ BAD: Trying to specify company_id
POST /v1/users
{
  "email": "[email protected]",
  "company_id": "some-other-company"  // This will be ignored/rejected
}

// ✅ GOOD: Let the API handle company_id
POST /v1/users
{
  "email": "[email protected]"
  // company_id is automatically set from JWT
}

3. Handle 404 Errors Properly​

A 404 response might mean:

  • The resource doesn't exist
  • The resource exists but belongs to another company

Both cases should be treated the same: the resource is not accessible.

Security Guarantees​

Console provides:

  • Automatic isolation: All queries are filtered by company_id
  • No cross-tenant access: Cannot access other companies' data
  • Middleware enforcement: Isolation is enforced at the API layer
  • Database-level filtering: All queries include company_id filter
For Product Users

Learn about multi-tenancy concepts in the UI: Multi-Tenancy Guide.