Deciding between endpoint or API-based filtering and online monitoring solutions can be challenging for network administrators.
As you research which tools are best for your district, it’s important to understand what endpoint and API network nodes mean for efficiency, student safety, and federal compliance.
There are pros and cons to both API and endpoint; understanding key advantages and disadvantages ensures you’re better positioned to make the best decision.
There are pros and cons to API and endpoint-based technology for digital monitoring and web filtering solutions.
The biggest advantage of API technology is the ability to monitor data transferred between a student's personal device and school systems. This allows you to better understand what students are doing on their personal devices.
For example: “What if a student uploads a compromising photo from their personal device to the school’s Google drive?”
API-based solutions can catch this.
However, honing in on activity made on personal devices can inadvertently create a tunnel-vision approach to student safety.
API-based technology can only filter and monitor students if they’re using school-managed applications such as Google Workspace or Office 365. For instance, if a student is logged into their school email, risks can be identified. But if a student talks about harming themselves on Facebook Messenger, for example, the school would be unable to see it on an API.
According to anonymized data from Linewize, the vast majority of online student activity occur beyond the boundaries of API.
As network administrators consider district needs, pricing, and comparisons between endpoint and API solutions, here are key questions to consider:
How many students use personal devices to access school resources?
What apps and websites are most commonly used?
Are the most commonly used apps and websites API?
What percentage of your traffic is coming from a device that your school did not issue?
What level of visibility is important for student safety in your district?
School safety is crucial in today’s digital learning environment. Proper school safety protocols ensure students are protected in and outside of school. As you consider different student threat detection and content filtering solutions, think about how endpoint and API both play a role in your student safety efforts.
Your district should prioritize holistic student safety and have a pulse on the capabilities and limitations of API and endpoint.
Endpoint technology makes it possible to monitor and filter anywhere, on any network, at any time. School issued-devices are always safeguarded, whether they’re on-network or off network.
On the other hand, API-based tech keeps a close eye on student activity when students are logged into school applications, like Google Classroom or Khan Academy. Although there’s less visibility into student activity outside of these APIs, the ability to identify safety risks on personal devices can be useful.
The capacity to accurately assess risks should be a priority for any school district. This is especially important in a modern educational environment where remote learning is commonplace and digital devices have become synonymous with schoolwork outside of the classroom.
Without endpoint technology, districts cannot identify potentially harmful online activity that occurs within the most commonly used applications. This is important to consider, as many potential risks occur outside of school hours.
For example, cyberbullying has become increasingly common; in 2021, Linewize found a child involved in a serious cyberbullying, bullying or violent incident every 22 minutes. Furthermore, an estimated 7 out of 10 people experience cyberbullying at least once before they turn 18.
In most cases, cyberbullying occurs on social media and over text. And unfortunately, a study from Statista found that kids spend 20% more time on social media than they did pre-pandemic.
As a result, a correlation between cyberbullying and the rise in social media usage is expected. Furthermore, many instances of cyberbullying are unlikely to be captured by API, as the chances of bullying are much less likely to occur directly within the school’s API-based applications.
Endpoint technology captures data based on keyboard input. This means that all student activity issued on a school device is assessed for potential risks. And while endpoint cannot see what a child does on social media and via text on their own device, as previously mentioned, API solutions can’t, either.
Instead, endpoint searches for the context clues that extend beyond personal devices and into school-issued devices.
Numerous statistics demonstrate that students who experience cyberbullying are at a higher risk of suicide. Symptoms of depression, self-harm thoughts, and bullying behavior can be identified on endpoint-based student threat detection software. These at-risk “clues” are often found in social media text, peer-to-peer chats, notes and documents, and search engine queries.
To summarize, here are some API pros and cons:
Monitor safety risks on a student’s personal device if using school applications
View historical risks
View risky activity on platforms that offer API integration (such as Google Classroom and Khan Academy)
Cannot view student activity on school-issued devices outside of the school’s integrated applications
Cannot view data outside of a small suite of APIs, including chat, emails, or documents
API integration often entails a hefty buy-in from school administrators
API integrations need to be created for each learning management system (LMS)
Integration can difficult if you use self-hosted versions of LMS tech like Canvas or Blackboard
API access is limited; many of the websites students use are not willing to share their API and therefore, when used, they cannot be monitored
Endpoint can access student activity on any school device, at any time, at any location
Risk-assess (either via AI or human moderation) student input data across Google, Office 365, offline documents, games, web chat, social media, and much more
Provides deeper level of context into potential risks; ability to view the entire desktop screen VS just the browser URL
Visibility into full-path URLs
Cannot view student activity on personal devices
Requires powerful endpoint security to protect devices from any location
Leaves gaps in mobile monitoring opportunities
Millions of students have been provided with school-issued devices, and many students use those devices for activities unrelated to schoolwork. Harmful online activity doesn’t just occur during school hours. For any district, it’s imperative to leverage the power of EdTech to protect student safety from every angle.
Want to know how endpoint works to protect your students? Our free Student Safety Audit program provides your school with actionable data and insights.
An Application Programming Interface (API) allows different pieces of software to interact with one another. The API infrastructure allows technologies to work together to facilitate the connection between two software solutions via “integrations.” For instance, Google Classroom integrates with many other tools—such as Khan Academy and filtering and monitoring technology like Linewize—via an API.
An Endpoint is any device used to access a network. The term “endpoint” refers technically to any device that communicates with a server, such as a Chromebook accessing Facebook or a Windows laptop playing an online game.
Endpoint monitoring means that the monitoring happens on the device itself– and it therefore can observe and flag risks in any application that is used on that device.
Think of “endpoint” as an extension of the Internet. An endpoint is a unit (such as a host computer connected to the TCP/IP network) at the end of a communication channel that’s accessed over a connected network.
Endpoints are connected elements of the Internet that consumes information and talks to other endpoints and systems across the network. Endpoints can generate immense amounts of data about their end-users.
In order for an API to work, developers/IT administrators have to provide the API with their own data to get desired results. Think of an API like going to a restaurant. After you decide what you want from the menu, the waiter sends your order to the chef and returns with your plate—but only if you hand over the ingredients. And because every API is different, you’ll need a separate integration for each.