Inter-College connects with the tools schools already use — payment recording, email, biometric attendance hardware, and Google Sign-In. Only one of these is genuinely live end to end — each card below says exactly where it stands, including the ones that do nothing at all today.
Fee payments are recorded by school staff against a payment mode — cash, cheque, demand draft, UPI, card, net banking, or Razorpay — with a receipt generated for each one. Razorpay's order ID and payment ID have dedicated fields on every receipt for your own reconciliation. Inter-College doesn't call the Razorpay API directly today: there's no parent-facing checkout and no automatic payment confirmation. A live, self-service checkout is on our roadmap.
Inter-College sends email through Zoho-hosted SMTP. In practice one email genuinely goes out today: the password reset. The rest of the machinery — per-tenant SMTP settings, HTML templates with variable substitution, a per-recipient delivery log that retries on failure — is written and has working endpoints, but no screen in the school portal drives it, and posting a notice does not email anyone.
Code exists to send WhatsApp messages through Meta's Cloud API — free text or pre-approved templates — and to record delivery and read receipts from its webhook. Be clear about what that is worth today: there is no screen anywhere, not even in our administrative back office, that lets a school enter the WhatsApp credentials the code needs, so in practice nothing can be sent. Treat this as groundwork, not a channel.
Staff and parent accounts that a school admin already created can sign in with Google instead of a password — a Google Identity Services ID token is verified server-side (signature, issuer, audience, and expiry) before anyone is logged in. It only authenticates an existing account; it never creates one. This is newly built and not switched on yet — it stays disabled until we configure our Google OAuth client ID, and returns a plain "not configured" response until then.
Fingerprint terminals that can POST a punch event to a URL — the model many biometric attendance devices use — can send clock-in and clock-out events straight into Inter-College. Each device authenticates with its own rotatable token, sends a heartbeat, and its punches are matched to the staff member enrolled against that device user. This is a staff punch log: there is no student-side biometric enrolment at all, no face recognition, no RFID or card reader support, and student attendance is always marked by a teacher.
MSG91 is set up as our SMS provider at the account-settings level, and there's a log model ready to record messages — but the sending pipeline itself isn't built yet. No API calls go out today. It's next on our list, not shipped.
The whole platform is a REST API — the portal and the mobile app are simply clients of it — and it is documented from the live schema rather than by hand. Enterprise customers get direct access to build against their existing ERP, HR or accounting software.
# Fetch student list
curl -X GET \
https://api.inter-college.com/api/v1/students/ \
-H "Authorization: Bearer <token>" \
-H "X-Tenant-Slug: springdale"
# Response
{
"count": 1200,
"next": null,
"previous": null,
"results": [
{
"id": 431,
"admission_number": "2025-0431",
"full_name": "Arjun Sharma",
"class_section": "10-A",
"roll_number": 15,
"status": "active"
}
]
}Every integration on this page is included at its real level of completeness, which for several of them is “not yet”. Start your free trial and check for yourself.