Design Considerations
Not All Systems are Created Equal
Not every system provides the same breadth or depth of data to Edlink. As such, there are some quirks you might want to take into consideration for your implementation.
Roles
Not every system gives us the data needed to determine a Person's roles. In these cases, roles
will be an empty array.
While a person may not have any roles, their Enrollments will. However, you shouldn't assume the role
will be consistent between all of a person's enrollments.
For instance, a person could be a teacher
in one Class while being a student
in another. This occurs most commonly when someone is a student
in a professional development class while being a teacher
in all of their other classes.
School-less Systems
Some systems do not have a concept of a School. In these cases, our system will create a fake school called the District Office. All Classes will belong to this fake school.
Syncing Data from Edlink
You should ensure your system has a mechanism to do a "full sync" of data from Edlink. This would involve paginating through the data you need for each Integration via our Graph API.
This is especially important if your primary sync mechanism relies on our events API. In case either system accidentally drops important information (e.g., due to an outage) it's useful to be able to run a "full sync" to get back to a good state. Additionally, the events API only goes back up to 30 days. You won't be able to observe any older events, as they are deleted from our system.
A "full sync" is also the preferred way to retrieve all data from Edlink for a new integration.
Don't Rely On Email Addresses
Click here to read our blog post about why email addresses aren't a good way to match users.
Generally, you should be using a Person's id
field to match users.