At Edlink, we specialize in creating a unified API layer that connects dozens of disparate educational platforms. If you're an LMS or SIS developer interested in having Edlink build an integration to your platform, this guide outlines the ideal API structure that enables a smooth, fast, and full-featured integration.
While we can and do work with many different API designs, following these guidelines will ensure that learning applications using Edlink can take full advantage of your platform's capabilities.
Core Principles
Ideally, your API should be a modern, RESTful service that uses JSON for data exchange. We also recommend the following:
- Authentication: Secure, token-based authentication, preferably OAuth 2.0.
- Identifiers: Every object (user, class, school, etc.) should have a stable, unique identifier that does not change.
- Pagination: Endpoints that return lists of objects should be paginated to handle large datasets efficiently. We prefer cursor-based pagination but can work with limit/offset.
- Webhooks (Optional): Providing webhooks for key events (e.g., a new enrollment) allows for more real-time data syncing.
Onboarding & Authentication
The first step for any school administrator is connecting their system to Edlink. A smooth onboarding experience is critical. We support two primary methods:
1. OAuth 2.0 Flow (Preferred)
This provides the best user experience. The administrator is guided through a standard OAuth 2.0 consent flow to authorize Edlink.
- Your platform should have an OAuth 2.0 server.
- The flow should result in an
access_tokenand arefresh_tokenthat Edlink can store to make subsequent API calls. - You should provide clear documentation on the required scopes for accessing rostering and coursework data.
- Ideally, the returned administrator tokens can provide broad-based access to the necessary endpoints without needing per-user tokens.
2. Static API Keys (Alternative)
If OAuth 2.0 is not available, we can support an onboarding flow where the administrator generates API credentials (e.g., a Client ID and Client Secret) within your platform's administrative UI. They would then copy and paste these values into their Edlink dashboard to establish the connection.
Single Sign-On (SSO)
A core feature for our clients is enabling users to sign in with their school credentials.
- OAuth 2.0 / OIDC: The preferred solution is to provide an OAuth 2.0 or OpenID Connect endpoint that Edlink can use to authenticate users.
- SAML: We can also support SAML-based SSO.
- LTI (for LMSs): For Learning Management Systems, supporting LTI 1.1 or 1.3 for authentication may be useful and enable unique user experiences.
Rostering Data Endpoints
The foundation of any integration is rostering data. We look for a set of RESTful endpoints to retrieve the core organizational structure and user data. These endpoints are just examples of our ideal structure; we can adapt to different designs as needed. It is our strong preference that you have bulk endpoints for data retrieval vs. having to make a call to each entity individually.
| Edlink Model | Ideal Endpoint(s) | Key Properties |
|---|---|---|
| Districts & Schools | GET /schools | id, name |
| Academic Sessions | GET /sessions | id, name, start_date, end_date |
| People | GET /people | id, first_name, last_name, email, roles (e.g., student, teacher) |
| Courses | GET /courses | id, title, course_code |
| Classes | GET /classes | id, title, course_id, session_id |
| Enrollments | GET /enrollments | id, person_id, class_id, role |
| Guardian Relationships | GET /agents | id, observer_id (parent), target_id (student), relationship_type |
Coursework & Grade Passback Endpoints
For a full-featured integration, we need endpoints to manage assignments and grades. These are typically nested under a specific class.
Assignments
GET /classes/{id}/assignments: List all assignments in a class.POST /classes/{id}/assignments: Create a new assignment.- Key Properties:
title,description,due_date,points_possible.
- Key Properties:
GET /classes/{id}/assignments/{id}: Fetch a single assignment.PATCH /classes/{id}/assignments/{id}: Update an assignment.DELETE /classes/{id}/assignments/{id}: Delete an assignment.
Grades & Submissions
Grades are typically managed as a property of a submission object, which links a student to an assignment.
GET /classes/{id}/assignments/{id}/submissions: List all student submissions for an assignment.GET /.../submissions/{id}: Fetch a single student's submission.PATCH /.../submissions/{id}: Update a submission, most commonly to post a grade.- Key Properties:
scoreorgrade_points,comment.
- Key Properties:
Next Steps
This document outlines our ideal API structure, but we are flexible. If your API differs, we can likely still build a successful integration.
To begin the conversation, please reach out to our support team.