Client Data Integrations

BTS offers several ways to integrate client data with their internal systems, ranging from flat-file exports and dashboards to API-based solutions and direct database access.

Integrations are especially useful for clients that:

• Use their own LMS, LRS, or analytics tools (e.g., Workday, Cornerstone, Tableau)
• Need frequent syncing of Momenta progress with other platforms
• Are tracking custom metrics beyond standard reporting

All integration projects begin with a scoping call between the project team, the data integration team, and the client’s technical contact.

Use these questions during early conversations with clients:

• Which LMS or data systems are you currently using?
• Do you prefer a customizable BTS dashboard, or direct data feeds?
• Who is the main technical contact for integration setup?
• What data needs to be shared (e.g., completions, attempts, responses)?
• How frequently should the data sync?
• What is the priority?
  • Accuracy
  • Real-time syncing
  • Fast retrieval

Which fields can be included at each level?

Note: Custom fields can be added on request, depending on the delivery method.

1. Flat File Export

• CSV or Excel format
• Ideal for one-time exports or small datasets
• Delivered manually or emailed on schedule

2. Read-Only Database Access

• Hosted in MongoDB or SQL
• Client receives example queries and read-only access

3. API Endpoint

• Hosted on MongoDB Realm
• URL pattern: https://{server}.data.mongodb-api.com/.../completions?secret=XXXX
• Filtered access by cohort, activity, or date range

4. Push Connector (Webhook)

• Data is pushed to the client's API on a schedule or trigger
• Requires:
  • Client endpoint URL
  • Auth headers (token or key)
  • Field mapping (expected payload structure)

1. The participant logs into Momenta and sees content based on the Journey Config documents
2. The participant interacts with Momenta, responding to questions, inputting feedback, booking calls, etc.
3. Most of this information is written to a MongoDB database, specific to their company
4. Some of this data is stored externally, via the Coach platform, Pulse, Isomer, or third-party programs accessed via a link
5. The data from the config docs, database, and applicable external data sources is sorted through and organized via a pre-defined pipeline
6. The organized data is loaded onto a dashboard or database that the client's data processing team can access and read

       *See Integration Options for more information on what “Aggregated Data” can look like.

• ACID - (Atomicity, Consistency, Isolation, Durability) This refers to a standard set of properties that guarantee database transactions are processed reliably. Each can be summarized as follows:
• Atomicity: Transactions (reads, writes, updates, etc.) are “all or nothing”. If one part of the transaction fails, the entire transaction fails.
• Consistency: Only valid data are saved. What counts as “valid” may vary from one database to another, but each has its own set of rules.
• Isolation: Transactions do not affect one another. Data that has not yet been written cannot be read.
• Durability: Written data will not be lost, even in the event of a system failure.
• API - (Application Programming Interface) In the context of data sharing, we specifically use Web APIs. A Web API is a set of pre-defined instructions which allows services and products to connect and communicate with each other programmatically. The term “API” can refer to the API Specification, the document detailing how to access and utilize the interface, which requests yield which results, etc., or to the implementation, the interface itself.
• CRUD Operations - (Create, Read, Update, Delete) These are the four functions available on any system which stores persistent data (e.g. a database). To create means that you are adding or writing data to the system, to read is to view existing data, to update is overwrite or alter existing data, and to delete is to remove existing data.
• Cloud Computing - The delivery of computing services (including servers, storage, databases, networking, software, analytics, and intelligence) over the Internet (the “cloud”). A company can have a third-party manage some or all of their infrastructure to reduce costs and management of that infrastructure.
• Collection (MongoDB) - A grouping of MongoDB documents, e.g. a basic unit of data. Databases are made up of collections which are made up of documents. The equivalent in a relational database (such as SQL) would be a table.
• Database - An organized collection of structured information, or data, typically stored electronically in a computer system.
• Data Lake - A centralized repository designed to store, process, and secure large amounts of structured, semi-structured, and unstructured data.
• Document (MongoDB) - A record in a MongoDB collection and the basic unit of data in MongoDB. Documents are analogous to JSON objects but exist in the database in a more type-rich format known as BSON. The equivalent in a relational database (such as SQL) would be a row (in a table).
• Document Database - Also known as a “NoSQL” databse, this is a type of nonrelational database that is designed to store and query data as JSON-like documents. Contrast relational databases, which store data in tables.
• Edge Computing - a distributed computing framework that brings enterprise applications as close to the source of data as possible in order to reduce latency and bandwidth use. In simpler terms, edge computing means running fewer processes in the cloud and moving those processes to local places, such as on a user’s computer, an IoT device, or an edge server.
• Endpoint - the Web-based URI to which applications address their API calls
• ETL - (Extract, Transform, Load) a process that extracts, transforms, and loads data from one or more sources to a data warehouse or other unified data repository.
• Horizontal Scaling - refers to increasing a system's capacity by adding more computers to the system. Most cloud systems use this method of scaling. Contrast with vertical scaling, increasing performance by adding more resources into one computer in the form of faster (or more) CPUs, memory or storage.
• HTTP Request - (Hypertext Transfer Protocol) An HTTP request is made by a client, to a named host, which is located on a server. The aim of the request is to access a resource on the server. An HTTP request is comprised of:
• The method: a one-word command that tells the server what it should do with the resource. The most common are GET, POST, PUT, or DELETE (for the read, write, update, and delete operations defined above, respectively).
• The path or endpoint: this part of the request looks like a URL and identifies the resource on the server.
• HTTP version number (typically “HTTP/1.1” or “HTTP/1.0” ).
• Headers: communicates information about the message, the sender, and the way in which the sender wants to communicate with the recipient. Each HTTP header is made up of a name and a value. Authorization will also typically be included as a header, e.g. "Authorization: Bearer eyJhbGciOiJI…".
• Body (optional): this is the actual content of the message, and will need to be included when sending a request which sends information to the server (e.g. POST or PUT).
• HTTP Response - An HTTP response is the what the server sends back to the client after receiving a request. The response is comprised of:
• A status code: three-digit code indicating the success/failure of the request. A complete list can be found here. Most common are:
• 200 (OK): Request has succeeded.
• 201 (Created): Request has succeeded and a new resource was created as a result.
• 204 (No Content): Request has succeeded and nothing is being returned in the response body (often used for DELETE requests).
• 400 (Bad Request): The server cannot or will not process the request due to something that is perceived to be a client error.
• 401 (Unauthorized) and 403 (Forbidden): The client does not have access rights to the content, either because they lack credentials (401) or they lack permission (403).
• 404 (Not Found): The server can not find the requested resource.
• 500 (Internal Server Error): The server has encountered a situation it does not know how to handle.
• Body: If the request succeeded, this will contain the information requested, typically in JSON or XML format.
• LMS - (Learning Management System) an e-learning software application that handles the delivery, administration, automation, and analytics of learning materials.
• LRS - (Learning Record Store) a server that is responsible for receiving, storing, and providing access to data from a learning system structured using xAPI.
• Relational Database (RDBMS) - a type of database that stores and provides access to data points that are related to one another, typically through the use of tables. Contrast document (or NoSQL) databases, which store data in documents.
• Replica Set - A cluster of MongoDB servers that implements replication and automated failover. An example would be three or more servers with one primary server and two or more secondary servers which continuously copy the primary.
• REST - (Representational State Transfer) an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other. REST-compliant or RESTful systems are stateless and separate the concerns of client and server. By using a REST interface, different clients hit the same REST endpoints, perform the same actions, and receive the same responses. The server does not need to know anything about what state the client is in and vice versa.
• Vertical Scaling - refers to increasing a system's performance by adding more resources into one computer in the form of faster (or more) CPUs, memory or storage. Contrast with horizontal scaling, increasing capacity by adding more computers to the system.
• SCORM - (Sharable Content Object Reference Model) a set of technical standards for eLearning software products. SCORM governs how online learning content and Learning Management Systems (LMSs) communicate with each other. A SCORM package refers to the content/data being shared, and a SCORM bridge describes a link between two SCORM compliant systems. There are multiple versions of SCORM, but BTS only supports SCORM 1.2, which tracks a single completion score.
• Serverless - an execution model where the cloud provider is responsible for executing some code or function by dynamically allocating the resources and only charging for the amount of resources used to run the code. There is a server being utilized, but it is managed entirely by a third-party.
• SOAP - (Simple Object Access Protocol) a standard messaging protocol for operating services like Windows and Linux to communicate via Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML). A SOAP API has stricter standards than a REST API, which has no official standards.
• WebHook - Also known as a “push API”, this is a client-side endpoint designed to receive data from a server after a given trigger. Contrast a more traditional, “pull API”, which is set up on a server for clients to send requests to.
• xAPI - Also called “Experience API” or “Tin Can API”, is a new specification for learning technology, similar to SCORM, wherein learning data is stored in the format “User + Verb + Object”. Although API is used in the name, xAPI generally refers more to the structure of the data being shared, rather than an endpoint queried by a client.

In addition to the above key terms, it can be helpful to be familiar with the more widely used data management programs.

• AWS: Amazon Web Services is a cloud computing provider that BTS utilizes for hosting configuration files and creating cloud servers that host our programs and databases.
• Azure: Azure hosts Microsoft's many cloud services. Azure Data Factory and Cosmos “serverless” databases are being looked at as potential solutions to creating fast and reliable pipelines to host and migrate larger amounts of data, such as telemetry.
• Cornerstone Learning: A learning management system used to create and track learning paths, competency, certifications, and more to manage employee training and education.
• MongoDB: Currently the most popular and widely used document database, MongoDB is how BTS stores all client data collected within Momenta and most information regarding a given client's journeys, cohorts, and other tools.
• Redis: An ETL service used to convert Momenta's MongoDB collections of documents into tables of rows for use in a tabular database, such as SQL.
• SQL: For many seasoned developers, Microsoft's SQL, the most widely adopted relational database, is the best and most familiar way of storing data. BTS uses SQL to store data tracked in Pulse and has utilized SQL for Momenta projects (via ETL) for clients that prefer to have their data represented in tables.
• Tableau: A visual analytics platform with a wide variety of customizable graphs, charts, and tables aimed at interpreting and managing data.
• Workday: A cloud-based software package designed and developed to manage enterprise resource planning, human capital management, and financial management applications. Workday offers a variety of different “suites” for Finance, HR, and Management which all contain different features.

• API Endpoint: https://data.mongodb-api.com/app/.../endpoint/data/beta/action/find
• Method: POST
• Header: API key + JSON content-type
• Body: Database, collection, filter
• Returns: JSON payload of activity-level user data

User Collection

Endpoint:  https://data.mongodb-api.com/app/data-wqacc/endpoint/data/beta/action/find

Method:   POST

Description:  Get all completion data from a specific journey on the client’s DB

Header Parameters :

1 | 'Content-Type' : 'application/json',
2 | 'Access-Control-Request-Headers' : '*'

1 | api-key: (created and issued to client)

1 | {
2 |    "collection" : "api_data",
3 |    "database" : "clientDB",
4 |    "dataSource" : "clientCluster",
5 |    "filter" : {}
6 | }

Output:

1  | {
2  |   "data":[
3  |      {
4  |         "_id": <string>,
5  |         "employee_id": <string>,
6  |         "course_id": <string>,
7  |         "journey": <string>,
8  |         "journey_id": <string>,
9  |         "cohort": <string>,
10 |         "cohort_id": <string>,
11 |         "stage": <string>,
12 |         "stage_id": <string>,
13 |         "module": <string>,
14 |         "module_id": <string>,
15 |         "activity": <string>,
16 |         "activity_id": <string>,
17 |         "status": <string>,
18 |         "started": <date>,
19 |         "completed": <date>
20 |      },
21 |      ...
22 |   ]
23 | }