Cross-Tenant Worker

By default an API key belongs to exactly one tenant: the worker daemon polling /jobs/next with that key only ever sees that tenant's configuration jobs. A cross-tenant worker key lifts that restriction so a single daemon + Revit machine can serve the job queues of all active tenants.

How it works

1. Cross-tenant API key: an API key created with isCrossTenant: true. Only super admins can create one (POST /api-key). It still has a home tenant (the creator's organization), which applies whenever no tenant header is sent.
2. Queue scan across tenants: when a cross-tenant key polls GET /jobs/next, the backend scans the house, block, and option-sales queues of all tenants and returns the highest-priority job. The job payload's tenantId identifies the tenant it belongs to.
3. X-Tenant-Id header: for every follow-up call (start/status/upload/finish/fail, project lookup, /tenants/me, blob downloads, …) the worker sends the job's tenant as an X-Tenant-Id header. The backend validates the tenant (must exist and be active) and runs the request in that tenant's context, including tenant settings such as coordinate system, Revit template, and default Revit version.
4. Job dispatch: the daemon passes the job's tenantId to the Revit add-in over the named pipe (configure, configure-block, configure-option-sales). The add-in keeps it as the ambient job tenant and stamps all of its own API calls with the same header until the job ends.

Regular (single-tenant) keys are rejected with 403 if they send an X-Tenant-Id other than their own tenant, and unknown or inactive tenants are rejected with 400. Every applied override is audit-logged on the backend.

Setting it up

1. As a super admin, create a cross-tenant API key:

   POST /api-key
   {
     "daysTillExpiration": 365,
     "name": "revit-worker-fleet",
     "isCrossTenant": true,
     "permissions": { "configuratorPermissions": ["READ_QUEUEJOBS"] }
   }

2. Put the key in the worker machine's ~/Alpha/settings.json as usual (apiKey / productionApiKey / …). No other daemon configuration is needed; the tenantId setting is now only a fallback for manual (non-job) runs.

3. Restart the AlphaWorkerDaemon. The log line Claimed <TYPE> job <id> (tenant=<tenantId>) confirms per-job tenant resolution is active.

Notes

• Manual runs in Revit (UI or CLI dispatch without a job) are unaffected: no job tenant is set, so calls run against the key's home tenant exactly as before.
• Revit versions per tenant still resolve per job: project.revitVersion → tenant default (/tenants/me with the job's tenant) → daemon settings.
• Heartbeat/registration still registers the agent under the tenant from local settings; the queue agent list shows which machine ran which job via worker events on the job itself.