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.

Connect Roster to n8nRead the Roster REST API documentation

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 approval

What n8n workflows can resolve

Approval routing
Select the current approver before creating an approval in Slack, Teams, email, a ticketing system, or another connected application.
Who should approve this CAD 75,000 purchase request?
Ticket assignment
Route a request to the participant responsible for a product, service, customer, or region.
Who owns this access request for the Atlas application?
Exception escalation
Resolve the correct escalation contact when a workflow encounters an error, timeout, or out-of-policy condition.
Who receives a severity-one billing escalation?
Cross-functional review
Add security, legal, finance, or procurement reviewers based on the workflow context.
Who should review this new subprocess from security and privacy?
Agent-to-human handoff
Give an automated workflow a governed way to find the person or group that should take over.
Who should handle this low-confidence customer response?
Delegated coverage
Route to the active delegate when the primary participant is unavailable.
Who is covering for the expense approver today?

Connect Roster to n8n

Use n8n's built-in HTTP Request node to call the Roster REST resolution endpoint documented for your deployment.

  1. Create a Roster identity for the workflow with access to the required projects and participants.
  2. Create a scoped Roster API key for that identity.
  3. Store the key in n8n credentials. Do not place it directly in node parameters or exported workflow JSON.
  4. Configure an HTTP Request node with the Roster REST endpoint and bearer authentication.
  5. Send a POST request to <your-roster-public-url>/api/v1/resolve with Content-Type: application/json.
  6. Include query, and include project_id when the workflow should resolve within a specific project. Use mode: "live" for production execution.
  7. Route the workflow using the Resolve response returned by Roster.
  8. 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:

  1. High-volume workflows.
  2. Tightly controlled request and response schemas.
  3. Predictable error branches.
  4. Workflows where participant resolution is always required.
  5. 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:resolve

Example: 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?
  1. The workflow prepares the resolution context.
  2. 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"
    }
  3. Roster evaluates the purchasing project, approval participants, threshold and region metadata, directory membership, active status, and delegations.
  4. n8n uses the Resolve response to create the approval task.
  5. 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.

Security and governance

Workflow identity
Use a dedicated Roster identity for each automation or security boundary where attribution and access differ.
Least privilege
Restrict scopes, projects, and tools to what the workflow needs.
Credential storage
Store Roster credentials in n8n credentials or the deployment's secret-management mechanism, not in node text or exported workflow JSON.
Controlled context
Send only the business context required to make the routing decision.
Explicit error branches
Handle not_found, out_of_scope, API errors, authentication, authorization, and service failure separately. Roster REST errors use RFC 9457 Problem Details, so branch on HTTP status and type rather than a legacy message field.
Auditable routing
Use Resolve Requests alongside n8n execution history when investigating a routing decision. Roster records live Resolve requests with the authenticated actor, subject to Resolve-history authorization and PII settings.

Frequently asked questions

No. The verified integration described here uses n8n's HTTP Request node and Roster's REST API.

Make human routing reusable across your n8n workflows

Keep automation logic in n8n and resolve current organizational responsibility through Roster whenever the workflow needs a person, group, role, or delegate.

Connect Roster to n8nRead the Roster REST API documentationExplore all integrations