How should an API decide which tenant a user is allowed to access?

Authorize tenant-scoped API requests

Explains trusted tenant context, membership checks, tenant-scoped queries, cache keys, and background job propagation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would derive tenant access from trusted server-side membership data, not from a raw tenant id sent by the browser. The route or header may identify the requested tenant, but the API verifies that the authenticated user belongs to that tenant and has the required role or capability. Data queries include tenant scope so a guessed id cannot cross boundaries, and the tenant id used for filtering comes from trusted request context.

Full answer below

Practice focus

Tenant context, memberships, route values, claims, query filters, admin tools, background jobs, and cache scope.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Tenant authorization is where authentication, data access, caching, jobs, and admin tooling meet. It must be treated as a system boundary.
I would derive tenant access from trusted server-side membership data, not from a raw tenant id sent by the browser. The route or header may identify the requested tenant, but the API verifies that the authenticated user belongs to that tenant and has the required role or capability. Data queries include tenant scope so a guessed id cannot cross boundaries, and the tenant id used for filtering comes from trusted request context.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would keep tenant context explicit through the request. Controllers, handlers, data queries, cache keys, audit events, and queued jobs should all carry the tenant boundary. Admin paths need extra care because they may intentionally cross tenants. Those actions should be capability-protected and audited. If tenant membership changes, cached permission or tenant-scoped data may need invalidation or short TTLs.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Trusting a tenant id from the client without membership validation.
Filtering tenant data in controllers but not background jobs.
Using cache keys that omit tenant scope.
Letting admin tools bypass tenant audit.

How should an API decide which tenant a user is allowed to access?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?