[Learning Tools Interoperability (LTI)](https://www.1edtech.org/standards/lti) is an open framework for building third-party integrations in learning management systems. While Classroom add-ons and [LTI tools](https://www.1edtech.org/standards/lti) support similar user journeys, the two frameworks are not directly compatible. This guide compares the two integration types and highlights key differences. It also suggests ways to achieve similar user journeys when adapting an LTI tool to work as a Classroom add-on. ## Interactions between platform and tools A key distinction between LTI tools and Classroom add-ons is the manner in which information is exchanged. LTI tools typically use HTTP `POST` to transmit payloads to an LTI platform, while Classroom add-ons create and retrieve resources using the [Google Classroom REST API](https://developers.google.com/workspace/classroom/reference/rest). The following table summarizes how to achieve key LTI tool behaviors with Google Classroom. | Feature | LTI | Classroom | |---|---|---| | Create assignments | Assignment \& Grade Services | Create [`CourseWork`](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.courseWork) and [`AddOnAttachment`](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.courseWork.addOnAttachments) resources | | Post grades | Assignment \& Grade Services | Patch [`CourseWork`](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.courseWork.studentSubmissions) and [`AddOnAttachment`](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.courseWork.addOnAttachments.studentSubmissions) student submissions | | Launch routes | Deep Linking | Specify URIs in [`AddOnAttachment` resources](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.courseWork.addOnAttachments#resource:-addonattachment) | | Read course rosters | Names \& Role Provisioning Services | Retrieve [`Student`](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.students#resource:-student) and [`Teacher`](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.teachers#resource:-teacher) profiles in a course | ## Adapt an LTI tool to Classroom add-on Many LTI interactions have analogues in the Classroom add-ons framework. The following sections discuss some key concepts and recommended courses of action. ### Configure your application All programmatic interactions with Google Classroom require a Google Cloud project. You'll configure your application listing in the same Cloud project, which defines how your Classroom add-on will appear to end users. You'll provide icons, set the app name and description, and configure the OAuth scope permissions that your product requires. Installing your add-on application from the listing is often the only configuration step that end users must perform. This is analogous to enabling and deploying an LTI tool. End users won't need to complete any registration actions or manage any configuration details, though an administrator might need to [allow the app in the Marketplace](https://developers.google.com/workspace/classroom/add-ons/developer-guides/project-configuration#individual_installation) and [configure third-party data access permissions](https://knowledge.workspace.google.com/admin/getting-started/editions/manage-access-to-unconfigured-third-party-apps-for-users-designated-as-under-18). **Recommendation** : Follow our guide to [creating and configuring a Google Cloud project for a Classroom add-on](https://developers.google.com/workspace/classroom/add-ons/developer-guides/project-configuration). Most importantly, specify a URL for the add-on launch as the **Attachment Discovery URI** in the Marketplace SDK. This URL can be the same as an existing LTI tool launch route as long as it routes the user to the appropriate [authentication flow](https://developers.google.com/workspace/classroom/add-ons/get-started/addons-lti-comparison#authentication-flow). ### Authentication flow LTI uses a [2-legged flow](https://www.imsglobal.org/spec/security/v1p1/#using-oauth-2-0-client-credentials-grant) in which a client application and authentication server exchange a signed JWT. Users don't need to grant a tool access to their data, as consent is implied when an administrator configures the tool. In contrast, Google's OAuth flow is a [3-legged flow](https://developers.google.com/identity/protocols/oauth2#webserver), involving the end user, external client application, and authentication server. The client receives tokens with explicit user consent that grant access to the user's Google Classroom resources. It is possible for a add-on application to achieve similar 2-legged signed-JWT behavior using **[service accounts](https://developers.google.com/identity/protocols/oauth2#serviceaccount)** . These are accounts that belong to an application instead of an individual user and can take action without user consent. Use of service accounts requires administrator configuration and management. Usage of service accounts with domain-wide delegation is strongly discouraged, as they are potential abuse vectors. See our guide to [domain-wide delegation with Google Classroom integrations](https://developers.google.com/workspace/classroom/guides/key-concepts/domain-wide-delegation) for more details. **Recommendation** : When a URL associated with your tool or add-on receives an incoming request, inspect the request for the presence of Classroom add-on [query parameters](https://developers.google.com/workspace/classroom/add-ons/developer-guides/iframes#query_parameters). If present, use the Google Identity SDK to obtain access credentials for the user. Store the credentials in the user's session and use them to make subsequent Classroom API requests. If the query parameters are not present, use HTTP requests to interact with the platform's LTI endpoints. ### Creating add-on content in Google Classroom Classroom add-ons support one type of content: URL links to pages hosted externally. These links are contained in [`AddOnAttachment` resources](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.courseWork.addOnAttachments#resource:-addonattachment), which define the web routes to open when a user interacts with your add-on. Each URL opens in specific scenarios, see our [iframes guides](https://developers.google.com/workspace/classroom/add-ons/get-started/user-journeys#views) for full details. These URLs are analogous to [LTI Resource Links](https://www.imsglobal.org/spec/lti-dl/v2p0#lti-resource-link). Classroom add-ons don't support other content types such as files, images, or HTML fragments. **Recommendation** : When a user selects content in your product, obtain their OAuth credentials and make an `AddOnAttachments.create` request. The request should contain an `AddOnAttachment` object containing the URLs for a student view, a teacher view, and (optionally) a grading view. Note that there are separate API endpoints for creating attachments on [announcements](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.announcements.addOnAttachments/create), [assignments](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.courseWork.addOnAttachments/create), or [course materials](https://developers.google.com/workspace/classroom/reference/rest/v1/courses.courseWorkMaterials.addOnAttachments/create). Only attachments created on assignments can have the grading view, as this is the only type of Classroom stream item that accepts a student submission. ## Framework feature comparison ### Integration placements Classroom add-ons create **attachments** on announcements, assignments, and course materials. These are the items that appear in a course's Stream tab in the Classroom UI. Teachers start the add-on attachment creation journey by selecting an add-on in a picker in the assignment creation flow. See the [iframes guides](https://developers.google.com/workspace/classroom/add-ons/get-started/user-journeys#views) for detailed discussion of each view presented to users. Alternatively, developers can programmatically create assignments with add-on attachments. See our guide to [creating attachments outside of Google Classroom](https://developers.google.com/workspace/classroom/add-ons/developer-guides/third-party-first-journey) for details. ### Launch context information Classroom appends several [query parameters](https://developers.google.com/workspace/classroom/add-ons/developer-guides/iframes#query_parameters) to each URL when opening an add-on route. These always include the stream item type and identifiers for the course and stream item. Other information may be present depending on the iframe view, such as the attachment or submission identifiers, a token to authorize attachment creation, or the URL to upgrade from a link to an add-on attachment. Classroom does not pass any information about the user or institution by default. You can obtain information about the user from the Classroom API [UserProfile resource](https://developers.google.com/workspace/classroom/reference/rest/v1/userProfiles), including a user ID. If the user is a domain administrator, you can obtain information about the institution from the [Workspace Admin SDK](https://developers.google.com/workspace/admin/overview). ### Authentication and authorization Classroom add-ons must use [Sign in with Google](https://developers.google.com/identity/gsi/web/guides/overview) for user authentication. Once signed in, users grant permission to your application through [OAuth 2.0 scopes](https://developers.google.com/identity/protocols/oauth2). Your application can use any combination of [available OAuth scopes](https://developers.google.com/identity/protocols/oauth2/scopes#classroom). ### App discovery and configuration Users find and "install" Classroom add-ons through the [Google Workspace Marketplace](https://workspace.google.com/marketplace/category/works-with-classroom). The one-click installation makes an add-on application available to an individual teacher. Optionally, an administrator can install the add-on application for all teachers in an organizational unit or domain. Attachments made with the application are then accessible by all students in a course. There is no need for end users to manage tokens, keys, or identifiers for individual Classroom add-ons. ### UX and product flow In many cases, an LTI tool's existing product flow works well as a Classroom add-on. Similar to an LTI tool, a Classroom add-on essentially lets you create and manage links to your content on our platform. Classroom add-on attachments are similar to LTI [Deep Linking links](https://www.imsglobal.org/spec/lti-dl/v2p0#link). If your LTI tool creates URLs that point to your hosted content, it should work well as a Classroom add-on. ### Grade student work Classroom add-on attachments can be viewed and graded in the Classroom grader view. When attaching content that requires a student submission, you provide a `student_work_review_uri` where an instructor can view and grade the work from a particular student. This is different from LTI, where a tool only defines a `target_link_uri` that is common to both teachers and students. The Classroom add-ons implementation is most similar to the upcoming [LTI Submission Review Service](https://www.imsglobal.org/spec/lti-sr/v1p0).