Users
API for accessing information on the current and other users.
Throughout this API, the :user_id
parameter can be replaced with self
as a shortcut for the id of the user accessing the API. For instance, users/:user_id/page_views
can be accessed as users/self/page_views
to access the current user's page views.
API for manipulating course nicknames
Course nicknames are alternate names for courses that are unique to each user. They are useful when the course's name is too long or less meaningful. If a user defines a nickname for a course, that name will be returned by the API in place of the course's actual name.
An UserDisplay object looks like:
An AnonymousUserDisplay object looks like:
An User object looks like:
A Profile object looks like:
An Avatar object looks like:
A PageView object looks like:
A PageViewLinks object looks like:
A CourseNickname object looks like:
GET /api/v1/accounts/:account_id/users
GET /api/v1/accounts/:account_id/users
Scope: url:GET|/api/v1/accounts/:account_id/users
A paginated list of users associated with this account.
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| The partial name or full ID of the users to match and return in the results list. Must be at least 3 characters.
Note that the API will prefer matching on canonical user ID if the ID has a numeric form. It will only search against other fields if non-numeric in form, or if the numeric value doesn’t yield any matches. Queries by administrative users will search on SIS ID, Integration ID, login ID, name, or email address |
|
| When set, only return users enrolled with the specified course-level base role. This can be a base role type of ‘student’, ‘teacher’, ‘ta’, ‘observer’, or ‘designer’. |
|
| The column to sort results by. Allowed values: |
|
| The order to sort the given column by. Allowed values: |
|
| When set to true and used with an account context, returns users who have deleted pseudonyms for the context |
Returns a list of User objects.
UsersController#activity_stream
GET /api/v1/users/self/activity_stream
GET /api/v1/users/self/activity_stream
Scope: url:GET|/api/v1/users/self/activity_stream
GET /api/v1/users/activity_stream
GET /api/v1/users/activity_stream
Scope: url:GET|/api/v1/users/activity_stream
Returns the current user’s global activity stream, paginated.
There are many types of objects that can be returned in the activity stream. All object types have the same basic set of shared attributes:
In addition, each item type has its own set of attributes available.
DiscussionTopic:
For DiscussionTopic, the message is truncated at 4kb.
Announcement:
For Announcement, the message is truncated at 4kb.
Conversation:
Message:
Submission:
Returns an Submission with its Course and Assignment data.
Conference:
Collaboration:
AssessmentRequest:
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| If true, will only return objects for courses the user is actively participating in |
UsersController#activity_stream_summary
GET /api/v1/users/self/activity_stream/summary
GET /api/v1/users/self/activity_stream/summary
Scope: url:GET|/api/v1/users/self/activity_stream/summary
Returns a summary of the current user’s global activity stream.
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| If true, will only return objects for courses the user is actively participating in |
Example Response:
GET /api/v1/users/self/todo
GET /api/v1/users/self/todo
Scope: url:GET|/api/v1/users/self/todo
A paginated list of the current user’s list of todo items.
There is a limit to the number of items returned.
The ‘ignore` and `ignore_permanently` URLs can be used to update the user’s preferences on what items will be displayed. Performing a DELETE request against the ‘ignore` URL will hide that item from future todo item requests, until the item changes. Performing a DELETE request against the `ignore_permanently` URL will hide that item forever.
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
|
Allowed values: |
Example Response:
UsersController#todo_item_count
GET /api/v1/users/self/todo_item_count
GET /api/v1/users/self/todo_item_count
Scope: url:GET|/api/v1/users/self/todo_item_count
Counts of different todo items such as the number of assignments needing grading as well as the number of assignments needing submitting.
There is a limit to the number of todo items this endpoint will count. It will only look at the first 100 todo items for the user. If the user has more than 100 todo items this count may not be reliable. The largest reliable number for both counts is 100.
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
|
Allowed values: |
Example Response:
UsersController#upcoming_events
GET /api/v1/users/self/upcoming_events
GET /api/v1/users/self/upcoming_events
Scope: url:GET|/api/v1/users/self/upcoming_events
A paginated list of the current user’s upcoming events.
Example Response:
UsersController#missing_submissions
GET /api/v1/users/:user_id/missing_submissions
GET /api/v1/users/:user_id/missing_submissions
Scope: url:GET|/api/v1/users/:user_id/missing_submissions
A paginated list of past-due assignments for which the student does not have a submission. The user sending the request must either be the student, an admin or a parent observer using the parent app
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| the student’s ID |
|
| Return missing submissions for the given observed user. Must be accompanied by course_ids[]. The user making the request must be observing the observed user in all the courses specified by course_ids[]. |
|
|
Allowed values: |
|
|
Allowed values: |
|
| Optionally restricts the list of past-due assignments to only those associated with the specified course IDs. Required if observed_user_id is passed. |
Returns a list of Assignment objects.
UsersController#ignore_stream_item
DELETE /api/v1/users/self/activity_stream/:id
DELETE /api/v1/users/self/activity_stream/:id
Scope: url:DELETE|/api/v1/users/self/activity_stream/:id
Hide the given stream item.
Example Request:
Example Response:
UsersController#ignore_all_stream_items
DELETE /api/v1/users/self/activity_stream
DELETE /api/v1/users/self/activity_stream
Scope: url:DELETE|/api/v1/users/self/activity_stream
Hide all stream items for the user
Example Request:
Example Response:
POST /api/v1/users/:user_id/files
POST /api/v1/users/:user_id/files
Scope: url:POST|/api/v1/users/:user_id/files
Upload a file to the user’s personal files section.
This API endpoint is the first step in uploading a file to a user’s files. See the File Upload Documentation for details on the file upload workflow.
Note that typically users will only be able to upload files to their own files section. Passing a user_id of self
is an easy shortcut to specify the current user.
GET /api/v1/users/:id
GET /api/v1/users/:id
Scope: url:GET|/api/v1/users/:id
Shows details for user.
Also includes an attribute “permissions”, a non-comprehensive list of permissions for the user. Example:
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| Array of additional information to include on the user record. “locale”, “avatar_url”, “permissions”, “email”, and “effective_locale” will always be returned Allowed values: |
Example Request:
Returns an User object.
POST /api/v1/accounts/:account_id/users
POST /api/v1/accounts/:account_id/users
Scope: url:POST|/api/v1/accounts/:account_id/users
Create and return a new user and pseudonym for an account.
DEPRECATED (for self-registration only)
If you don’t have the “Modify
login details for users“ permission, but self-registration is enabled on the account, you can still use this endpoint to register new users. Certain fields will be required, and others will be ignored (see below).
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| The full name of the user. This name will be used by teacher for grading. Required if this is a self-registration. |
|
| User’s name as it will be displayed in discussions, messages, and comments. |
|
| User’s name as used to sort alphabetically in lists. |
|
| The time zone for the user. Allowed time zones are IANA time zones or friendlier Ruby on Rails time zones. |
|
| The user’s preferred language, from the list of languages Canvas supports. This is in RFC-5646 format. |
|
| Whether the user accepts the terms of use. Required if this is a self-registration and this canvas instance requires users to accept the terms (on by default).
If this is true, it will mark the user as having accepted the terms of use. |
|
| Automatically mark the user as registered.
If this is true, it is recommended to set
The users communication channel confirmation can be skipped by setting |
| Required | User’s login ID. If this is a self-registration, it must be a valid email address. |
|
| User’s password. Cannot be set during self-registration. |
|
| SIS ID for the user’s account. To set this parameter, the caller must be able to manage SIS permissions. |
|
| Integration ID for the login. To set this parameter, the caller must be able to manage SIS permissions. The Integration ID is a secondary identifier useful for more complex SIS integrations. |
|
| Send user notification of account creation if true. Automatically set to true during self-registration. |
|
| Send user a self-registration style email if true. Setting it means the users will get a notification asking them to “complete the registration process” by clicking it, setting a password, and letting them in. Will only be executed on if the user does not need admin approval. Defaults to false unless explicitly provided. |
|
| The authentication provider this login is associated with. Logins associated with a specific provider can only be used with that provider. Legacy providers (LDAP, CAS, SAML) will search for logins associated with them, or unassociated logins. New providers will only search for logins explicitly associated with them. This can be the integer ID of the provider, or the type of the provider (in which case, it will find the first matching provider). |
|
| The communication channel type, e.g. ‘email’ or ‘sms’. |
|
| The communication channel address, e.g. the user’s email address. |
|
| Only valid for account admins. If true, returns the new user account confirmation URL in the response. |
|
| Only valid for site admins and account admins making requests; If true, the channel is automatically validated and no confirmation email or SMS is sent. Otherwise, the user must respond to a confirmation message to confirm the channel.
If this is true, it is recommended to set |
|
| If true, validations are performed on the newly created user (and their associated pseudonym) even if the request is made by a privileged user like an admin. When set to false, or not included in the request parameters, any newly created users are subject to validations unless the request is made by a user with a ‘manage_user_logins’ right. In which case, certain validations such as ‘require_acceptance_of_terms’ and ‘require_presence_of_name’ are not enforced. Use this parameter to return helpful json errors while building users with an admin request. |
|
| When true, will first try to re-activate a deleted user with matching sis_user_id if possible. This is commonly done with user and communication_channel so that the default communication_channel is also restored. |
|
| If you’re setting the password for the newly created user, you can provide this param with a valid URL pointing into this Canvas installation, and the response will include a destination field that’s a URL that you can redirect a browser to and have the newly created user automatically logged in. The URL is only valid for a short time, and must match the domain this request is directed to, and be for a well-formed path that Canvas can recognize. |
|
| ‘observer` if doing a self-registration with a pairing code. This allows setting the password during user creation. |
|
| If provided and valid, will link the new user as an observer to the student’s whose pairing code is given. |
Returns an User object.
UsersController#create_self_registered_user
POST /api/v1/accounts/:account_id/self_registration
POST /api/v1/accounts/:account_id/self_registration
Scope: url:POST|/api/v1/accounts/:account_id/self_registration
Self register and return a new user and pseudonym for an account.
If self-registration is enabled on the account, you can use this endpoint to self register new users.
Request Parameters:
Parameter | Type | Description |
---|---|---|
| Required | The full name of the user. This name will be used by teacher for grading. |
|
| User’s name as it will be displayed in discussions, messages, and comments. |
|
| User’s name as used to sort alphabetically in lists. |
|
| The time zone for the user. Allowed time zones are IANA time zones or friendlier Ruby on Rails time zones. |
|
| The user’s preferred language, from the list of languages Canvas supports. This is in RFC-5646 format. |
| Required | Whether the user accepts the terms of use. |
| Required | User’s login ID. Must be a valid email address. |
|
| The communication channel type, e.g. ‘email’ or ‘sms’. |
|
| The communication channel address, e.g. the user’s email address. |
Returns an User object.
GET /api/v1/users/:id/settings
GET /api/v1/users/:id/settings
Scope: url:GET|/api/v1/users/:id/settings
PUT /api/v1/users/:id/settings
PUT /api/v1/users/:id/settings
Scope: url:PUT|/api/v1/users/:id/settings
Update an existing user’s settings.
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| If true, require user to manually mark discussion posts as read (don’t auto-mark as read). |
|
| If true, hide the badge for new release notes. |
|
| If true, the user’s page loads with the global navigation collapsed |
|
| If true, the user’s course pages will load with the course navigation collapsed. |
|
| If true, images on course cards will be presented without being tinted to match the course color. |
|
| If true, suggestions within the comment library will be shown. |
|
| If true, will display the user’s preferred class Canvas dashboard view instead of the canvas for elementary view. |
Example Request:
UsersController#get_custom_colors
GET /api/v1/users/:id/colors
GET /api/v1/users/:id/colors
Scope: url:GET|/api/v1/users/:id/colors
Returns all custom colors that have been saved for a user.
Example Request:
Example Response:
UsersController#get_custom_color
GET /api/v1/users/:id/colors/:asset_string
GET /api/v1/users/:id/colors/:asset_string
Scope: url:GET|/api/v1/users/:id/colors/:asset_string
Returns the custom colors that have been saved for a user for a given context.
The asset_string parameter should be in the format ‘context_id’, for example ‘course_42’.
Example Request:
Example Response:
UsersController#set_custom_color
PUT /api/v1/users/:id/colors/:asset_string
PUT /api/v1/users/:id/colors/:asset_string
Scope: url:PUT|/api/v1/users/:id/colors/:asset_string
Updates a custom color for a user for a given context. This allows colors for the calendar and elsewhere to be customized on a user basis.
The asset string parameter should be in the format ‘context_id’, for example ‘course_42’
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| The hexcode of the color to set for the context, if you choose to pass the hexcode as a query parameter rather than in the request body you should NOT include the ‘#’ unless you escape it first. |
Example Request:
Example Response:
UsersController#set_text_editor_preference
PUT /api/v1/users/:id/text_editor_preference
PUT /api/v1/users/:id/text_editor_preference
Scope: url:PUT|/api/v1/users/:id/text_editor_preference
Updates a user’s default choice for text editor. This allows the Choose an Editor propmts to preload the user’s preference.
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| The identifier for the editor. Allowed values: |
Example Request:
Example Response:
UsersController#get_dashboard_positions
GET /api/v1/users/:id/dashboard_positions
GET /api/v1/users/:id/dashboard_positions
Scope: url:GET|/api/v1/users/:id/dashboard_positions
Returns all dashboard positions that have been saved for a user.
Example Request:
Example Response:
UsersController#set_dashboard_positions
PUT /api/v1/users/:id/dashboard_positions
PUT /api/v1/users/:id/dashboard_positions
Scope: url:PUT|/api/v1/users/:id/dashboard_positions
Updates the dashboard positions for a user for a given context. This allows positions for the dashboard cards and elsewhere to be customized on a per user basis.
The asset string parameter should be in the format ‘context_id’, for example ‘course_42’
Example Request:
Example Response:
PUT /api/v1/users/:id
PUT /api/v1/users/:id
Scope: url:PUT|/api/v1/users/:id
Modify an existing user. To modify a user’s login, see the documentation for logins.
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| The full name of the user. This name will be used by teacher for grading. |
|
| User’s name as it will be displayed in discussions, messages, and comments. |
|
| User’s name as used to sort alphabetically in lists. |
|
| The time zone for the user. Allowed time zones are IANA time zones or friendlier Ruby on Rails time zones. |
|
| The default email address of the user. |
|
| The user’s preferred language, from the list of languages Canvas supports. This is in RFC-5646 format. |
|
| A unique representation of the avatar record to assign as the user’s current avatar. This token can be obtained from the user avatars endpoint. This supersedes the user [avatar] [url] argument, and if both are included the url will be ignored. Note: this is an internal representation and is subject to change without notice. It should be consumed with this api endpoint and used in the user update endpoint, and should not be constructed by the client. |
|
| To set the user’s avatar to point to an external url, do not include a token and instead pass the url here. Warning: For maximum compatibility, please use 128 px square images. |
|
| To set the state of user’s avatar. Only valid for account administrator. Allowed values: |
|
| Sets a title on the user profile. (See Get user profile.) Profiles must be enabled on the root account. |
|
| Sets a bio on the user profile. (See Get user profile.) Profiles must be enabled on the root account. |
|
| Sets name pronunciation on the user profile. (See Get user profile.) Profiles and name pronunciation must be enabled on the root account. |
|
| Sets pronouns on the user profile. Passing an empty string will empty the user’s pronouns Only Available Pronouns set on the root account are allowed Adding and changing pronouns must be enabled on the root account. |
|
| Suspends or unsuspends all logins for this user that the calling user has permission to Allowed values: |
|
| Default is true. If false, any fields containing “sticky” changes will not be updated. See SIS CSV Format documentation for information on which fields can have SIS stickiness |
Example Request:
Returns an User object.
UsersController#terminate_sessions
DELETE /api/v1/users/:id/sessions
DELETE /api/v1/users/:id/sessions
Scope: url:DELETE|/api/v1/users/:id/sessions
Terminates all sessions for a user. This includes all browser-based sessions and all access tokens, including manually generated ones. The user can immediately re-authenticate to access Canvas again if they have the current credentials. All integrations will need to be re-authorized.
UsersController#expire_mobile_sessions
DELETE /api/v1/users/mobile_sessions
DELETE /api/v1/users/mobile_sessions
Scope: url:DELETE|/api/v1/users/mobile_sessions
DELETE /api/v1/users/:id/mobile_sessions
DELETE /api/v1/users/:id/mobile_sessions
Scope: url:DELETE|/api/v1/users/:id/mobile_sessions
Permanently expires any active mobile sessions, forcing them to re-authorize.
The route that takes a user id will expire mobile sessions for that user. The route that doesn’t take a user id will expire mobile sessions for all users in the institution.
PUT /api/v1/users/:id/merge_into/:destination_user_id
PUT /api/v1/users/:id/merge_into/:destination_user_id
Scope: url:PUT|/api/v1/users/:id/merge_into/:destination_user_id
PUT /api/v1/users/:id/merge_into/accounts/:destination_account_id/users/:destination_user_id
PUT /api/v1/users/:id/merge_into/accounts/:destination_account_id/users/:destination_user_id
Scope: url:PUT|/api/v1/users/:id/merge_into/accounts/:destination_account_id/users/:destination_user_id
Merge a user into another user. To merge users, the caller must have permissions to manage both users. This should be considered irreversible. This will delete the user and move all the data into the destination user.
User merge details and caveats: The from_user is the user that was deleted in the user_merge process. The destination_user is the user that remains, that is being split.
Avatars: When both users have avatars, only the destination_users avatar will remain. When one user has an avatar, will it will end up on the destination_user.
Terms of Use: If either user has accepted terms of use, it will be be left as accepted.
Communication Channels: All unique communication channels moved to the destination_user. All notification preferences are moved to the destination_user.
Enrollments: All unique enrollments are moved to the destination_user. When there is an enrollment that would end up making it so that a user would be observing themselves, the enrollment is not moved over. Everything that is tied to the from_user at the course level relating to the enrollment is also moved to the destination_user.
Submissions: All submissions are moved to the destination_user. If there are enrollments for both users in the same course, we prefer submissions that have grades then submissions that have work in them, and if there are no grades or no work, they are not moved.
Other notes: Access Tokens are moved on merge. Conversations are moved on merge. Favorites are moved on merge. Courses will commonly use LTI tools. LTI tools reference the user with IDs that are stored on a user object. Merging users deletes one user and moves all records from the deleted user to the destination_user. These IDs are kept for all enrollments, group_membership, and account_users for the from_user at the time of the merge. When the destination_user launches an LTI tool from a course that used to be the from_user’s, it doesn’t appear as a new user to the tool provider. Instead it will send the stored ids. The destination_user’s LTI IDs remain as they were for the courses that they originally had. Future enrollments for the destination_user will use the IDs that are on the destination_user object. LTI IDs that are kept and tracked per context include lti_context_id, lti_id and uuid. APIs that return the LTI ids will return the one for the context that it is called for, except for the user uuid. The user UUID will display the destination_users uuid, and when getting the uuid from an api that is in a context that was recorded from a merge event, an additional attribute is added as past_uuid.
When finding users by SIS ids in different accounts the destination_account_id is required.
The account can also be identified by passing the domain in destination_account_id.
Example Request:
Returns an User object.
POST /api/v1/users/:id/split
POST /api/v1/users/:id/split
Scope: url:POST|/api/v1/users/:id/split
Merged users cannot be fully restored to their previous state, but this will attempt to split as much as possible to the previous state. To split a merged user, the caller must have permissions to manage all of the users logins. If there are multiple users that have been merged into one user it will split each merge into a separate user. A split can only happen within 180 days of a user merge. A user merge deletes the previous user and may be permanently deleted. In this scenario we create a new user object and proceed to move as much as possible to the new user. The user object will not have preserved the name or settings from the previous user. Some items may have been deleted during a user_merge that cannot be restored, and/or the data has become stale because of other changes to the objects since the time of the user_merge.
Split users details and caveats:
The from_user is the user that was deleted in the user_merge process. The destination_user is the user that remains, that is being split.
Avatars: When both users had avatars, both will be remain. When from_user had an avatar and destination_user did not have an avatar, the destination_user’s avatar will be deleted if it still matches what was there are the time of the merge. If the destination_user’s avatar was changed at anytime after the merge, it will remain on the destination user. If the from_user had an avatar it will be there after split.
Terms of Use: If from_user had not accepted terms of use, they will be prompted again to accept terms of use after the split. If the destination_user had not accepted terms of use, hey will be prompted again to accept terms of use after the split. If neither user had accepted the terms of use, but since the time of the merge had accepted, both will be prompted to accept terms of use. If both had accepted terms of use, this will remain.
Communication Channels: All communication channels are restored to what they were prior to the merge. If a communication channel was added after the merge, it will remain on the destination_user. Notification preferences remain with the communication channels.
Enrollments: All enrollments from the time of the merge will be moved back to where they were. Enrollments created since the time of the merge that were created by sis_import will go to the user that owns that sis_id used for the import. Other new enrollments will remain on the destination_user. Everything that is tied to the destination_user at the course level relating to an enrollment is moved to the from_user. When both users are in the same course prior to merge this can cause some unexpected items to move.
Submissions: Unlike other items tied to a course, submissions are explicitly recorded to avoid problems with grades. All submissions were moved are restored to the spot prior to merge. All submission that were created in a course that was moved in enrollments are moved over to the from_user.
Other notes: Access Tokens are moved back on split. Conversations are moved back on split. Favorites that existing at the time of merge are moved back on split. LTI ids are restored to how they were prior to merge.
Example Request:
Returns a list of User objects.
UsersController#pandata_events_token
POST /api/v1/users/self/pandata_events_token
POST /api/v1/users/self/pandata_events_token
Scope: url:POST|/api/v1/users/self/pandata_events_token
Returns a jwt auth and props token that can be used to send events to Pandata.
NOTE: This is currently only available to the mobile developer keys.
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| The pandata events appKey for this mobile app |
Example Request:
Example Response:
UsersController#user_graded_submissions
GET /api/v1/users/:id/graded_submissions
GET /api/v1/users/:id/graded_submissions
Scope: url:GET|/api/v1/users/:id/graded_submissions
GET /api/v1/users/:user_id/profile
GET /api/v1/users/:user_id/profile
Scope: url:GET|/api/v1/users/:user_id/profile
Returns user profile data, including user id, name, and profile pic.
When requesting the profile for the user accessing the API, the user’s calendar feed URL and LTI user id will be returned as well.
Returns a Profile object.
ProfileController#profile_pics
GET /api/v1/users/:user_id/avatars
GET /api/v1/users/:user_id/avatars
Scope: url:GET|/api/v1/users/:user_id/avatars
A paginated list of the possible user avatar options that can be set with the user update endpoint. The response will be an array of avatar records. If the ‘type’ field is ‘attachment’, the record will include all the normal attachment json fields; otherwise it will include only the ‘url’ and ‘display_name’ fields. Additionally, all records will include a ‘type’ field and a ‘token’ field. The following explains each field in more detail
type
“gravatar”|“attachment”|“no_pic”
The type of avatar record, for categorization purposes.
“gravatar”|“attachment”|“no_pic”
The type of avatar record, for categorization purposes.
“gravatar”|“attachment”|“no_pic”
The type of avatar record, for categorization purposes.
url
The url of the avatar
token
A unique representation of the avatar record which can be used to set the avatar with the user update endpoint. Note: this is an internal representation and is subject to change without notice. It should be consumed with this api endpoint and used in the user update endpoint, and should not be constructed by the client.
display_name
A textual description of the avatar record
id
‘attachment’ type only
the internal id of the attachment
content-type
‘attachment’ type only
the content-type of the attachment
filename
‘attachment’ type only
the filename of the attachment
size
‘attachment’ type only
the size of the attachment
Example Request:
Example Response:
Returns a list of Avatar objects.
GET /api/v1/users/:user_id/page_views
GET /api/v1/users/:user_id/page_views
Scope: url:GET|/api/v1/users/:user_id/page_views
Return a paginated list of the user’s page view history in json format, similar to the available CSV download. Page views are returned in descending order, newest to oldest.
Request Parameters:
Parameter | Type | Description |
---|---|---|
|
| The beginning of the time range from which you want page views. |
|
| The end of the time range from which you want page views. |
Returns a list of PageView objects.
PUT /api/v1/users/:user_id/custom_data(/*scope)
PUT /api/v1/users/:user_id/custom_data(/*scope)
Scope: url:PUT|/api/v1/users/:user_id/custom_data(/*scope)
Store arbitrary user data as JSON.
Arbitrary JSON data can be stored for a User. A typical scenario would be an external site/service that registers users in Canvas and wants to capture additional info about them. The part of the URL that follows /custom_data/
defines the scope of the request, and it reflects the structure of the JSON data to be stored or retrieved.
The value self
may be used for user_id
to store data associated with the calling user. In order to access another user’s custom data, you must be an account administrator with permission to manage users.
A namespace parameter, ns
, is used to prevent custom_data collisions between different apps. This parameter is required for all custom_data requests.
A request with Content-Type multipart/form-data or Content-Type application/x-www-form-urlencoded can only be used to store strings.
Example PUT with multipart/form-data data:
Response:
Subscopes (or, generated scopes) can also be specified by passing values to data
[subscope
].
Example PUT specifying subscopes:
Response:
Following such a request, subsets of the stored data to be retrieved directly from a subscope.
Example GET from a generated scope
Response:
If you want to store more than just strings (i.e. numbers, arrays, hashes, true, false, and/or null), you must make a request with Content-Type application/json as in the following example.
Example PUT with JSON data:
Response:
If the data is an Object (as it is in the above example), then subsets of the data can be accessed by including the object’s (possibly nested) keys in the scope of a GET request.
Example GET with a generated scope:
Response:
On success, this endpoint returns an object containing the data that was stored.
Responds with status code 200 if the scope already contained data, and it was overwritten by the data specified in the request.
Responds with status code 201 if the scope was previously empty, and the data specified in the request was successfully stored there.
Responds with status code 400 if the namespace parameter, ns
, is missing or invalid, or if the data
parameter is missing.
Responds with status code 409 if the requested scope caused a conflict and data was not stored. This happens when storing data at the requested scope would cause data at an outer scope to be lost. e.g., if /custom_data
was {“fashion_app”: {“hair”: “blonde”}}, but you tried to ‘PUT /custom_data/fashion_app/hair/style -F data=buzz`, then for the request to succeed,the value of /custom_data/fashion_app/hair
would have to become a hash, and its old string value would be lost. In this situation, an error object is returned with the following format:
Request Parameters:
Parameter | Type | Description |
---|---|---|
| Required | The namespace under which to store the data. This should be something other Canvas API apps aren’t likely to use, such as a reverse DNS for your organization. |
| Required | The data you want to store for the user, at the specified scope. If the data is composed of (possibly nested) JSON objects, scopes will be generated for the (nested) keys (see examples). |
Example Request:
Example Response:
GET /api/v1/users/:user_id/custom_data(/*scope)
GET /api/v1/users/:user_id/custom_data(/*scope)
Scope: url:GET|/api/v1/users/:user_id/custom_data(/*scope)
Load custom user data.
Arbitrary JSON data can be stored for a User. This API call retrieves that data for a (optional) given scope. See Store Custom Data for details and examples.
On success, this endpoint returns an object containing the data that was requested.
Responds with status code 400 if the namespace parameter, ns
, is missing or invalid, or if the specified scope does not contain any data.
Request Parameters:
Parameter | Type | Description |
---|---|---|
| Required | The namespace from which to retrieve the data. This should be something other Canvas API apps aren’t likely to use, such as a reverse DNS for your organization. |
Example Request:
Example Response:
CustomDataController#delete_data
DELETE /api/v1/users/:user_id/custom_data(/*scope)
DELETE /api/v1/users/:user_id/custom_data(/*scope)
Scope: url:DELETE|/api/v1/users/:user_id/custom_data(/*scope)
Delete custom user data.
Arbitrary JSON data can be stored for a User. This API call deletes that data for a given scope. Without a scope, all custom_data is deleted. See Store Custom Data for details and examples of storage and retrieval.
As an example, we’ll store some data, then delete a subset of it.
Example PUT with valid JSON data:
Response:
Example DELETE:
Response:
Example GET following the above DELETE:
Response:
Note that hashes left empty after a DELETE will get removed from the custom_data store. For example, following the previous commands, if we delete /custom_data/veggies/root/onion, then the entire /custom_data/veggies scope will be removed.
Example DELETE that empties a parent scope:
Response:
Example GET following the above DELETE:
Response:
On success, this endpoint returns an object containing the data that was deleted.
Responds with status code 400 if the namespace parameter, ns
, is missing or invalid, or if the specified scope does not contain any data.
Request Parameters:
Parameter | Type | Description |
---|---|---|
| Required | The namespace from which to delete the data. This should be something other Canvas API apps aren’t likely to use, such as a reverse DNS for your organization. |
Example Request:
Example Response:
CourseNicknamesController#index
GET /api/v1/users/self/course_nicknames
GET /api/v1/users/self/course_nicknames
Scope: url:GET|/api/v1/users/self/course_nicknames
Returns all course nicknames you have set.
Example Request:
Returns a list of CourseNickname objects.
CourseNicknamesController#show
GET /api/v1/users/self/course_nicknames/:course_id
GET /api/v1/users/self/course_nicknames/:course_id
Scope: url:GET|/api/v1/users/self/course_nicknames/:course_id
Returns the nickname for a specific course.
Example Request:
Returns a CourseNickname object.
CourseNicknamesController#update
PUT /api/v1/users/self/course_nicknames/:course_id
PUT /api/v1/users/self/course_nicknames/:course_id
Scope: url:PUT|/api/v1/users/self/course_nicknames/:course_id
Set a nickname for the given course. This will replace the course’s name in output of API calls you make subsequently, as well as in selected places in the Canvas web user interface.
Request Parameters:
Parameter | Type | Description |
---|---|---|
| Required | The nickname to set. It must be non-empty and shorter than 60 characters. |
Example Request:
Returns a CourseNickname object.
CourseNicknamesController#delete
DELETE /api/v1/users/self/course_nicknames/:course_id
DELETE /api/v1/users/self/course_nicknames/:course_id
Scope: url:DELETE|/api/v1/users/self/course_nicknames/:course_id
Remove the nickname for the given course. Subsequent course API calls will return the actual name for the course.
Example Request:
Returns a CourseNickname object.
CourseNicknamesController#clear
DELETE /api/v1/users/self/course_nicknames
DELETE /api/v1/users/self/course_nicknames
Scope: url:DELETE|/api/v1/users/self/course_nicknames
Remove all stored course nicknames.
Example Request:
© Instructure, Inc. Generated on Wed Nov 6 14:20:10 2024 This documentation is generated directly from the Canvas LMS source code, available on Github.
Last updated