Introduction
The Learn365 Reporting API lets you pull Learn365 data directly into your favorite reporting tool -- most commonly Power BI or any tool that can read an OData feed. Use it to build custom dashboards, combine Learn365 data with data from other systems, or run one-off analyses that go beyond Learn365's built-in reports.
What is the Learn365 Reporting API?
The Learn365 Reporting API is a read-only data feed at https://api.365.systems/reporting. You point your reporting tool at it, choose which tables you want, and the tool loads the data for you to visualize and model. It's built on the widely-supported OData v4 standard, so most modern BI tools recognize it out of the box.
Connect to the Learn365 Reporting API
The base URL is https://api.365.systems/reporting
Authentication
The Learn365 Reporting API uses standard HTTP Basic authentication:
- Username: api
- Password: your Learn365 API key
Connect Power BI to the Learn365 Reporting API
1. Open Power BI Desktop.
2. Go to Get Data > OData feed.
3. Paste the URL of the feed you want to load. You'll find a full list of feeds and tables in the interactive documentation. For more information, see Additional resources.
4. When prompted for credentials, select Basic.
5. Enter api as the username and your API key as the password.
The Navigator lists the available tables. Choose the ones you want then select Load. Alternatively, select Transform Data to shape them first.
Explore the Learn365 Reporting APIs
The Learn365 Reporting API is available here: https://api.365.systems.
1. Scroll to the bottom of the Overview section.
2. Select Learn365 Reporting API from the Select a definition drop-down. The Learn365 Reporting API opens.
You can browse all tables, expand each one to see its columns, and try requests directly from this page.
Understanding the data
There are a couple of design choices worth knowing before you start building reports.
The tables are flat
Each table has just the columns of that entity plus foreign-key IDs to related entities. For example, an Enrollments row has a UserId and a CourseId, but not the full user or course as a nested object. This keeps every request small and fast.
You join tables in your report, not in the API
Because the tables are flat, all joins happen inside your reporting tool. Power BI is excellent at this: load the tables you need, then define relationships between them in the Model view.
Some relationships are many-to-many. For those, Learn365 provides dedicated bridge tables (sometimes called junction or link tables).
| Bridge table | Connects |
|---|---|
| CourseQuizzes | Courses ↔ Quizzes |
| CourseScorms | Courses ↔ SCORM packages |
| CourseCategoryMappings | Courses ↔ Categories |
| TrainingPlanCourses | Training Plans ↔ Courses |
| CourseSkills | Courses ↔ Skills |
| UserSkills | Users ↔ Skills |
| GroupMembers | Groups ↔ Users |
| UserExternalReferences | Users ↔ external system IDs |
| ScormExternalReferences | SCORM ↔ external IDs |
To connect two entities that aren't directly related, load the bridge table and let Power BI use it to route filters between them.
Known limitations
The Reporting API is intentionally lightweight, but there are some important boundaries:
- Read-only. Only GET requests are allowed. There are no create, update, or delete operations, no batch operations, and no server-side functions or actions.
- No individual-record endpoints. You always work with whole tables (with filters), not Table(id)-style single-record lookups.
- No nested data. Relationships are exposed as foreign-key IDs only. $expand isn't useful; bridge tables are how you join.
- Server-side paging at 10,000 rows. Every response contains at most 10,000 rows. If there is more data, the response includes an @odata.nextLink pointing to the next page. Your reporting tool follows this link automatically; you don't need to do anything special. There is no limit to the total number of rows you can pull, just on how many come back in a single response.
- $top behavior. You can still send $top to limit how much you want in total, but you can't use it to get more than 10,000 rows in a single response.
- Per-request timeout. Very large single responses can hit a server-side timeout. If a request is slow, add a $filter to narrow it, or let paging handle it.
- Fair-use rate limits may apply. The API is shared infrastructure. Scheduled report refreshes are the right pattern; high volumes of requests within a short period may result in throttling.
- Data freshness. The API returns the current committed state of your data. There is no separate real-time or streaming mode.
Comments
Article is closed for comments.