Trust and procurement
Because Schoolyi is self-hosted, most of the third parties a school worries about are ones you enable rather than ones we impose. This page enumerates every external service the application can reach, what data would flow to it, and what triggers that flow - taken from the integration code and environment templates rather than from a generic trust statement.
A useful trust answer explains controls, responsibilities, and boundaries plainly.
At a glance
The full list of third parties a Schoolyi deployment can send data to, which of them are optional, and which are off unless you switch them on.
Use the linked product and documentation pages to validate the workflow against your school’s data, roles, policies, and deployment.
Read the supporting materialHow it works
A clear sequence makes ownership, exceptions, and the next system action visible.
A deployment with no integrations configured sends student data to no third party. The application and database sit on your server, and outbound calls only begin when you supply credentials for a service.
Email needs an SMTP provider. Online fee collection needs one payment gateway, and only the one you select. Maps need a geocoding service. Each is independently optional.
For each service you enable, write down what data leaves, who the provider is, and where they process it. The list on this page gives you the first column; the rest depends on the accounts you hold.
A published list is not a legal instrument. Get processing roles, transfer safeguards, deletion, and return terms in a signed agreement covering your deployment before production data is loaded.
Stated facts
Taken from the integration code and environment templates in the product repository. "Optional" means the service is contacted only when you configure credentials for it; with no credentials, that flow does not exist.
Verified against the product code on .
| Question | Answer | Basis |
|---|---|---|
| Email delivery (SMTP provider of your choice) | Optional, and needed for anything that emails a family: verification, password reset, fee receipts, admissions correspondence, reminders. Recipient addresses and message content go to the provider you configure. Without SMTP credentials, these features do not send. | Your deployment |
| Payment gateway - Razorpay, Stripe, or Telr | Optional, and only the one you select is contacted. Fee amounts and payer context are sent to create and verify a payment. The default configuration uses a simulated checkout that contacts nobody. | Your deployment |
| Geocoding and map tiles (OpenStreetMap and tile providers) | Optional in practice: contacted only when a staff member uses a map or address lookup. An address string or coordinate pair is sent; tiles load in the browser. | Your deployment |
| AI assistant | A local model on the same server, reachable only on localhost. Staff questions and retrieved context stay on your host. One external download fetches the model file at install. | In the product |
| Error reporting webhook | Optional and off by default. If you set a webhook URL, error messages and a stack snippet are posted to it. With no URL, errors go to the server log only. | Your deployment |
| Activity log export to your SIEM | Outbound only when your own collector calls the export endpoint with its shared secret. We do not push it anywhere. | In the product |
| SMS | Not implemented. The SMS provider writes to the server log and reports success without sending. No phone number leaves the server, and no SMS vendor is a subprocessor - but no SMS is delivered either. | Not available |
| No API integration. The product generates a link a staff member clicks, which opens their own WhatsApp client. The message is sent by that person from their own account. | Not available | |
| Push notifications | Not available. No push service is integrated, so no device token is collected or shared. Notifications appear in the application and by email. | Not available |
| Analytics inside the application | None. There is no analytics or telemetry integration in the logged-in product, and no usage data is reported to us. | In the product |
| TLS certificates | Issued automatically by a public certificate authority for the hostnames you serve. This exposes your hostnames, as it does for any public website, and no school data. | Your deployment |
| Processing roles, transfers, deletion and return | For a signed agreement covering your deployment. The list above tells you what to write into it; it is not itself a commitment. | Agree in writing |
Product truth
Good school software copy should answer who owns the work, what the handoff produces, and which parts still depend on deployment decisions.
This page describes the supported workflow boundary. Confirm configuration, integrations, data, and policy requirements in a representative pilot before committing to production.
Deep dive
Use these details to turn a product page into an implementation conversation.
A hosted product hands you a subprocessor list you must accept. Here you are the controller of the host itself, so the meaningful question is not which subprocessors we use but which ones you have switched on. Two schools running the same version can have completely different answers.
SMS does not leave the server: the provider writes to the log rather than sending, so treat SMS as unimplemented rather than as a data flow. WhatsApp is a link a staff member clicks, not an API integration. Both matter if your questionnaire asks who receives parent phone numbers.
When an integration is enabled, record its credentials owner, data fields, provider terms, retention, and disable procedure. A deployment-specific register is more accurate than a universal vendor list.
Evidence layer
Read the supporting product and implementation material before making a capability claim.
Straightforward answers for visitors evaluating the product.
None, in the sense that matters: with no integration credentials configured, no student, family, or staff data leaves your server. Every external service listed on this page is switched on by supplying your own credentials for it.
Record the responsible administrator and verify the control in the target deployment before production data is loaded. Keep the evidence with the school’s procurement or access-review record.
The logged-in application has no analytics integration at all. The public marketing site can use privacy-preserving page analytics, and it is disabled unless a domain is configured. Nothing reports your usage back to us.
Record the responsible administrator and verify the control in the target deployment before production data is loaded. Keep the evidence with the school’s procurement or access-review record.
No. The assistant runs a local model on the same server as the application, reachable only on localhost. The only external call is a one-time model file download at install. If the AI worker is disabled, there is no call at all.
Treat that boundary as an explicit procurement or deployment decision. Document the responsible owner and any supporting process before rollout.
One at most - whichever you select. Card gateways for India, international, and the Gulf are each supported, but only the configured one is contacted, and the default configuration takes no live payments.
Validate credentials, permissions, and failure handling in a non-production environment before connecting live school records. Assign an owner for monitoring the handoff after launch.
No, and it is not meant to. It exists so the factual half of your questionnaire can be answered from a public page instead of a sales call, which should make the legal half faster rather than unnecessary.
Record the responsible administrator and verify the control in the target deployment before production data is loaded. Keep the evidence with the school’s procurement or access-review record.
No. External services generally require deployment credentials or an explicit configuration. Verify the environment and document any service your school enables.
Treat that boundary as an explicit procurement or deployment decision. Document the responsible owner and any supporting process before rollout.
Continue exploring
Follow the next link based on the question your team needs to answer.
Data residency and backups
Where a Schoolyi deployment actually stores school data, what the backup does and does not cover, and the recovery questions we cannot answer for you yet.
Read the pageSchool software procurement questionnaire
A practical questionnaire for evaluating school software across workflows, data, security, implementation, support, and total cost.
Read the page
We can walk through the workflow with your school’s roles, calendar, data, and first-term priorities.
Already using Schoolyi? Sign in
