Platform & Partners
Tenant Admin
What tenant admins (workspace users) can do in the recruiter portal, and how they see credentials provisioned by their platform admin.
Tenant admins are regular workspace users with the admin role within their customer workspace. They interact with Teamcast through the Recruiter Console (/recruiter), not the Platform Console. Their permissions are scoped to their own tenant — they cannot see or modify data belonging to other tenants.
Dashboard redirect
After login, a user whose roleDiscriminator is tenant_user is redirected to /recruiter. The sidebar items visible to them are determined by their permissions[]array, just like the Platform Console.
Recruiter console capabilities
| Area | Path | What the tenant admin can do |
|---|---|---|
| Jobs | /recruiter/jobs | Create, edit, archive job openings; set interview plan parameters |
| Candidates | /recruiter/jobs/:id/candidates | Add candidates, view pipeline, track interview status |
| Plan review (HITL-1) | /recruiter/assessment | Approve or reject AI-generated interview plans |
| Assessment review (HITL-2) | /recruiter/assessment/:id | Review coverage summary, flag issues, close interviews |
| Analytics | /recruiter/analytics | Role-level coverage profiles and pipeline analytics |
| API Keys | /recruiter/integrations/api-keys | View and manage API keys for their workspace |
| Webhooks | /recruiter/integrations/webhooks | Configure a webhook endpoint for interview events |
| OAuth Apps | /recruiter/integrations/oauth-clients | Manage OAuth 2.1 clients for their workspace |
Integration credentials visibility
API keys, webhook configs, and OAuth clients created by the platform admin for a customer tenant appear in that tenant's /recruiter/integrations pages alongside any self-provisioned credentials. There is no visual distinction — they share the same list.
| Tab | Reads from | Can tenant admin manage? |
|---|---|---|
| API Keys | GET /api-keys | Yes — can create, edit, revoke (within their own permissions) |
| Webhooks | GET /me/webhook-config | Yes — can upsert or delete (requires webhook:update permission) |
| OAuth Apps | GET /oauth-clients | Yes — can create and manage TENANT-audience clients |
tenantId regardless of who created them. A key created by the platform admin for Liha is indistinguishable from one Liha's admin created themselves — both are returned by GET /api-keys when called with Liha's session.API key permissions available to tenant users
Tenant admins cannot grant an API key more permissions than they hold themselves (the self-serve escalation guard in ApiKeyController.create). The default set used by the UI is:
| Permission | What the API key can do |
|---|---|
| interview:create | Submit a new interview request via the A2A endpoint |
| interview:read | Read interview details, status, and assessment results |
| interview:approve | Approve or reject interview plans (HITL-1) via API |
| interview:update | Update interview metadata (job description, candidate info) |
| candidate:read | Read candidate profiles linked to interviews |
| recording:read | Download interview recordings |
| webhook:read | Read webhook delivery logs |
platform:* permissions can never be embedded in an API key, regardless of who creates it. This is enforced server-side.LinkedIn POC: using a platform-provisioned key
In the LinkedIn POC, the platform admin (LinkedIn) provisions an API key for the customer workspace (e.g. Liha) from the Platform Console. To wire up the POC instance to use this key:
- Create the API key for Liha in
/admin/integrations/api-keys— copy the raw key (shown once). - Set
TEAMCAST_API_KEY=tc_live_...in the POC's.env. - All tc-core operations in the POC will now run in Liha's tenant context — interviews, candidates, assessments, and webhook events are all scoped to Liha.