It is acceptable to enable scopes on the Canvas developer key used with an Edlink integration. Some institutions may even require this as a matter of security policy. However, Canvas' current behavior imposes trade-offs that limit recommending scoped keys broadly.
There are two primary reasons, one technical and one operational:
Enabling scopes disables the Canvas GraphQL API
When scopes are enabled on a Canvas developer key, the GraphQL API is effectively unavailable for that key. The underlying reason is not publicly documented. Edlink relies on GraphQL for most rostering operations because it reduces API traffic and allows retrieval of compound objects in a single call (e.g., course + sections + enrollments) instead of multiple REST calls.
Scope management is error-prone and hard to maintain at scale
Canvas exposes a large number of highly granular scopes tied to specific REST endpoints. This makes configuration easy to misapply and complicates future changes (e.g., switching to improved endpoints) because each institution must update its scopes. Edlink supports approximately a thousand Canvas instances; coordinating per-instance scope adjustments is not feasible at this scale.
Fallback behavior
Edlink provides REST fallbacks for all GraphQL queries it uses. While REST requests are slower and generate more API traffic, they ultimately produce the same results.