Export tasks
This page contains information on the available endpoints for the MTM Connect OUT API. The text that follows contains specifics on the type of data that may be retrieved as well as the necessary steps. Using the export endpoints, MTM Connect OUT clients may extract the necessary information.
MTM Connect OUT API endpoints for data retrieval
/api/v{version}/Vendors
Retrieves information on the related client organization. Obtains information on all vendors connected to events where data was gathered.
/api/v{version}/Courses
Retrieves the information on all courses associated with the grouping of learning events. Obtains information on all courses connected to events where data was gathered.
/api/v{version}/Locations
Retrieves the details about the locations where the learning events are facilitated.
/api/v{version}/Instructors
Retrieves the details on the instructor who facilitates learning events.
/api/v{version}/Clients
Retrieves data on all clients connected to vendors or attached to events using the data gathered.
/api/v{version}/BusinessUnits
Retrieves data on student grouping by email domains as provided by the client.
/api/v{version}/Classes
Retrieves data on learning events with data gathered in the last five years or with open surveys.
/api/v{version}/Enrollments
Retrieves data about students who were enrolled in a learning event.
/api/v{version}/Forms
Retrieves data about surveys conducted to get feedback on learning events.
/api/v{version}/Questions
Retrieves data on the questions that appear on forms.
/api/v{version}/QuestionCategories
Retrieves the information of the grouping of questions.
/api/v{version}/Responses
Retrieves data on how students responded to a survey form.
/api/v{version}/DemographicResponses
Retrieves the demographics of the learners who responded to a survey.
To try the methods/endpoints, check out the MTM Connect API Swagger. To understand the data relationship, check out the MTM_Connect_API_Data_Relationship_Diagram. This entity relationship diagram is available to assist clients joining results from multiple endpoints; however, if that is not sufficient, then support should be able to work with clients to ensure the setting up of the data correctly. Key columns connect each entity to another entity. Check out MTM API - Conceptual relationship to learn more about connecting entities based on relationships between entities.
Extract data from MTM
MTM Connect OUT clients can extract data from the system by using the export endpoint. The latest MTM Connect API version is v1.
Step 1: The first step is to verify if the client is authentic. The client's access token is validated to check if the client can export data into the system. . A detailed explanation of the authentication processes may be found at MTM Connect API -Authentication.
Step 2: Input data on Vendor, Course, Locations, Instructors, Clients, Business Units, Classes, Enrollment, Forms, Questions, Question Categories, Responses and Demographic Reponses elements can be extracted using the export endpoints. Some data points (such as ClassID, RespondentIdentifier, etc.) are accessible via many endpoints, and the client is free to use any of them. Although the client may not need to request each endpoint if integrating MTM data with data from other systems, the fields exist across several endpoints to ease joining.
Better data consistency across endpoints
The new DataLoadingStartDate, which selects existing data from all endpoints that are between and equal to the data loading start date and the current date, has enhanced MTM Connect OUT API implementations by making data available based on the class start date (refer to the table below for more details). This ensures increased data consistency across all endpoints. Additionally, existing API users are not needed to take any action or re-pull the past data.
| Endpoint | Available data |
|---|---|
| Class | All self-paced web-based classes & all classes with a start date > or = DataLoadingStartDate. |
| Answer | All answer data from classes in the Class endpoint. |
| Demographic | All demographics tied to classes in the Class endpoint. |
| Question | All questions that are currently tied to an answer in the Answer Endpoint and all questions tied to a form tied to a class in the Class endpoint. |
| Form | All forms (including survey pages) tied to data in the Answer endpoint AND all forms tied to a class in the Class endpoint |
The previous approach for data availability in Connect OUT would result in certain "orphaned IDs," which are IDs that existed in one endpoint but weren't present in the primary endpoint under specific circumstances. Examples of these special circumstances include questions that were retired from all surveys, which would appear in the Answer endpoint but be excluded from the Question endpoint, and surveys that had been removed from a class after data was collected, which would appear in the Answer endpoint but not the Form endpoint. The client was unable to map the ID to the other identifying information because of these orphaned IDs. With the application of the new data availability logic, all relevant IDs are picked while orphaned IDs are reduced.
The last modification date in the API is indicated by lastmodifieddate. This is usually the same date as when it was changed in MTM, but if there is ever a delay in moving data from MTM to the API endpoints, the lastmodifieddate in the API will allow you to retrieve that new data the next time you make a request.
If you expect to see a record in the API but it isn't there or has an older lastmodifieddate than you require, the simplest solution is to modify that item directly in MTM. The API should be updated simply by pushing Update on the edit page. Remember that it might take up to 15 minutes for updates to display in the API.
MTM ID vs. External ID
MTM ID is the unique identifier within the MTM system, whereas External ID (also referred to as XID) refers to the identifier that is provided from an external system. MTM IDs is a generic term used when referring to asset identifiers within the MTM system. There are MTM IDs for all assets: MTM ClassID, MTM CourseID, MTM LocationID, MTM InstructorID, etc. These IDs are used for querying, troubleshooting, giving data rights, and more on the MTM side. They are created automatically by MTM when the asset is created in the system for the first time.
The best practice is for the parent organization to be designated as the instance organization and to add or import classes at the parent level. If you encounter challenges in identifying the instance organization post-API implementation, you can either define an instance organization during the implementation process or seek assistance from support to confirm it. This approach ensures that all data, such as XIDs, are kept at the parent level and not distributed among the children. If your instance organization is not the import organization, you won't see XIDs in your OUT results.
However, in cases where data has been imported into an organization that is not the instance org, users can assign the import organization as the instance organization and adhere to one or more of the following guidelines:
- Users can choose to have multiple Connect OUT instances, thereby establishing multiple instance organizations to accommodate the imported data.
- Users should consider reconfiguring the import integration to align with the best practice of importing data into a single parent organization.
MTM Connect OUT endpoints that can be used to extract data, its API call, and the description of its parameters are given below. To try out these endpoints, check out the MTM Connect API Swagger. The throttling period will be 10 seconds for all these endpoints.
In the MTM Connect OUT the data can be requested multiple times a day; best practice is to request it once or twice a day based on volume.
The client can try this out using the MTM Connect API sample application. The sample client app in C# can be found here - GITHub - explorance/exploranceapis-mtmconnect-csharp.
InMTM Connect OUT API
InMTM Connect OUT API
InMTM Connect OUT API