How LTI® Roster Access Works
The short answer
Names and Role Provisioning Services lets your tool read the list of people in a course and what role each holds. It is one read-only endpoint, called when you need it. It is not a sync — nothing tells you when somebody enrols or drops.
It is specified as Names and Role Provisioning Services 2.0 by 1EdTech Consortium, Inc.
What it is for
A launch tells you about one person: whoever clicked. That is enough for most things and not enough for some.
You need the roster when you have to know about people who have not launched yet — building groups, showing a teacher their class, marking who has not started, creating accounts ahead of time. Anything where "who is in this course" is a question rather than "who is here now".
Making the call
Like the other services, this needs an access token rather than the launch itself. One scope covers it:
https://purl.imsglobal.org/spec/lti-nrps/scope/contextmembership.readonly
Read-only, deliberately. There is no way to change an enrolment through LTI®.
The response is the members of a context — a course — each with an identifier, a role list, and whatever personal data the platform is willing to release.
Useful filters, where the platform supports them: by role, to fetch only students; by resource link, to get the people with access to one specific activity rather than the whole course.
Roles are a list, not a word
The roles claim is a list of URIs, and a user can hold several at once:
"roles": [
"http://purl.imsglobal.org/vocab/lis/v2/membership#Learner",
"http://purl.imsglobal.org/vocab/lis/v2/institution/person#Student"
]
Two things follow.
Match on the full URI. There are institution-level roles and context-level
roles, and they look similar. Searching for the substring Student will match an
institution role that says nothing about this course.
Expect combinations. A teaching assistant may be both a Learner and a Mentor. A lecturer taking a colleague's course is an Instructor in one and a Learner in another. Code that assumes one role per person will mis-handle real courses, usually in the ones that matter.
The context-level roles are Learner, Instructor, ContentDeveloper, Mentor, Administrator and Manager. Learner and Instructor cover almost everything.
Personal data is not guaranteed
This is the part that surprises people.
The platform decides what to release, and many institutions release nothing — no names, no email addresses, just opaque identifiers. That is a legitimate configuration and often a legal requirement rather than an oversight.
So a roster can come back as a list of identifiers and roles with no human-readable names in it at all. If your interface has a column headed "Name", it needs something to show when there is nothing to show.
Two consequences worth designing for:
- Do not require an email address to create an account. It will fail at exactly the institutions that care most about privacy.
- Do not match users across systems by email. Addresses get reused, changed and
shared, and the same address at two institutions is not necessarily one person.
The stable identity is the issuer plus the
subclaim.
It is a pull, not a push
Nothing notifies you of a change. If a student enrols after you last called, you will not know until you call again.
That makes when you call a design decision. Fetching on every launch is expensive and rude to the LMS on a large course. Caching means acting on a stale roster. The usual compromise is caching with a short life plus a manual refresh where being current actually matters.
Some platforms support asking only for what changed since your last call, which is the efficient answer for a large course. Support is uneven, so treat it as an optimisation rather than something to depend on.
What LTIAAS handles
The token exchange and pagination, so reading a roster is one request:
const { members } = await axios.get(
'https://your.ltiaas.com/api/memberships',
{ headers: { Authorization: `LTIK-AUTH-V2 ${API_KEY}:${ltik}` } }
).then(r => r.data)
Pagination links are surfaced rather than hidden, including the changed-since-last-call relation where a platform offers it. Member fields are normalised across platforms — different LMSes put the same information under different names — while leaving everything the platform sent available, so a platform-specific field is still reachable when you need it.
Filters for role, resource link and page size are passed through as query parameters. The roster API guide has the detail, and the names and roles flow has a worked example.
Common questions
What is Names and Role Provisioning?
An LTI® Advantage service that lets a tool read the list of people in a course, with their roles. One endpoint, read-only, called when the tool needs it.
Is it a roster sync?
No. It is a pull, not a push — nothing notifies you when someone enrols or drops. If you need current data you have to call again, which makes when you call a design decision.
Will I get names and email addresses?
Not necessarily. The platform decides how much personal data to release, and many institutions are configured to send none. Design for a roster of opaque identifiers and treat names as a bonus.
How do I tell students from teachers?
The roles claim, which is a list of URI values rather than a single word. A user can hold several, and matching on the full URI rather than a substring avoids confusing an institution role with a course role.
Next
- How LTI® grade passback works
- The LTI® 1.3 security model — including personal data
- Roster API guide
