Roster for n8n
Resolve the right person before the workflow routes the work.
Connect n8n to Roster's REST API so workflows can select current approvers, owners, reviewers, escalation contacts, and delegates from governed organizational context.
n8n automates the workflow. Roster resolves who should act within it.
Last verified 07/14/2026
Static assignees break otherwise dynamic workflows
n8n can connect applications, transform data, run AI agents, and automate multi-step processes.
But a workflow often reaches a routing question that application data alone cannot answer:
“Who should approve this purchase?”
“Who owns this customer in this region?”
“Who reviews this access request?”
“Who receives the escalation after two failed attempts?”
“Who is covering for the normal approver?”
A fixed email address in a node works only until responsibilities change. Large decision tables reproduce org structure inside the workflow and become difficult to maintain across automations. Roster centralizes the participant model and lets n8n resolve the answer at runtime.
How Roster fits into an n8n workflow
This is a direct API integration: n8n supplies the workflow context, Roster returns the resolved participant, and n8n performs the next action.
n8n trigger or workflow
↓
HTTP Request node
↓
Roster REST API
↓
Project + participant model
↓
Directory users, groups, roles, memberships, and delegations
↓
Resolved participant
↓
n8n routes the task, message, ticket, or approvalWhat n8n workflows can resolve
Connect Roster to n8n
Use n8n's built-in HTTP Request node to call the Roster REST resolution endpoint documented for your deployment.
- Create a Roster identity for the workflow with access to the required projects and participants.
- Create a scoped Roster API key for that identity.
- Store the key in n8n credentials. Do not place it directly in node parameters or exported workflow JSON.
- Configure an HTTP Request node with the Roster REST endpoint and bearer authentication.
- Send a POST request to <your-roster-public-url>/api/v1/resolve with Content-Type: application/json.
- Include query, and include project_id when the workflow should resolve within a specific project. Use mode: "live" for production execution.
- Route the workflow using the Resolve response returned by Roster.
- Add separate branches for not_found, out_of_scope, error, authentication failure, authorization failure, and service failure.
Example request body:
{
"query": "Who should approve this CAD 75,000 software purchase for the Canadian operations team?",
"project_id": "proj_123",
"mode": "live"
}The API key requires the api:resolve scope. Its effective access remains limited by the key owner's Roster permissions and the target resource rules.
This pattern is appropriate for:
- High-volume workflows.
- Tightly controlled request and response schemas.
- Predictable error branches.
- Workflows where participant resolution is always required.
- Workflows that need a currently verified connection between n8n and Roster.
Roster returns a resolution status of success, not_found, out_of_scope, or error. Roster REST errors use RFC 9457 Problem Details, so branch on HTTP status and the stable type field rather than a legacy message field.
REST resolution scope
For resolve-only automations, keep scopes narrow. Effective access remains constrained by the key owner's Roster permissions and target-resource rules.
api:resolveExample: route a purchase approval
An n8n form trigger receives a purchase request with the amount, business unit, region, and vendor risk.
“Who should approve this CAD 75,000 software purchase for the Canadian operations team?”
- The workflow prepares the resolution context.
- The HTTP Request node calls Roster's resolution API with the workflow context:
POST <your-roster-public-url>/api/v1/resolve Authorization: Bearer $ROSTER_API_KEY Content-Type: application/json { "query": "Who should approve this CAD 75,000 software purchase for the Canadian operations team?", "project_id": "proj_123", "mode": "live" } - Roster evaluates the purchasing project, approval participants, threshold and region metadata, directory membership, active status, and delegations.
- n8n uses the Resolve response to create the approval task.
- A not_found, out_of_scope, API error, or authorization response follows a separate exception branch.
The workflow never guesses an assignee, and every routing decision is auditable through Resolve Requests alongside n8n execution history.
Roster complements n8n
n8n remains responsible for triggers, integrations, data transformation, workflow execution, retries, notifications, approvals, and application updates.
Roster supplies the organizational decision needed before the workflow chooses a human participant. It does not replace n8n workflow logic, credentials, or application connectors.