Enforcing User-Agent Header for Canvas API Requests

[SarahCornelius]

Introducing Stronger API Governance in Canvas

Data privacy and security is more important than ever before. We’re deeply committed to protecting the data of our institution users AND our partners–that’s why we're excited to share several improvements to our API security and monitoring framework. 

For integration partners, the key update is that beginning October 1, our Beta environment will reject any HTTP requests that do not include a User-Agent header. This change will be deployed to our Production environment on January 17, 2026.

This enforces a best practice across our platform and throughout the software industry aligning with our broader goals for API governance, observability, and security.

 

Why This Matters to You

Enhanced Security
Requests lacking a User-Agent often come from automation or misconfigured scripts—and can signal scraping or other unwanted behaviors. Blocking these helps reduce our threat surface and better protects the platform.

Improved Observability & Governance
A valid User-Agent is crucial for attributing requests to their source. This enables better audit trails, usage insights, and accountability—essential elements of a robust API governance model.

Operational Efficiency
Having clean, traceable API traffic allows for faster debugging, usage pattern analysis, and resource allocation. It helps us support teams more effectively while maintaining system reliability.

 

How This Affects You

• Automated tools, scripts, or cron jobs that don’t explicitly set a User-Agent will begin failing with a 403 error code.
  
  
• Standard browsers and many HTTP clients already include a User-Agent—so most normal interactions remain unaffected.

 

What You Should Do Next

 

Language Specific Examples

 

Additional Updates to User Access Tokens

Beyond enforcing the User-Agent header, we’re also making several changes for Canvas Admins to help ensure efficient and appropriate management of API access. These updates are planned for early Q4 and include:

• Requiring that all user access tokens have a purpose listed
• Requiring that all user access tokens for users with only student roles have an expiration date not more than 120 days from the date of creation
• Enabling administrators to prevent users with only student roles from creating user access tokens
• Enabling administrators to more easily view and remove user access tokens