REST API and webhooks with KIDUART
If your school runs an internal system a website, an attendance device, a reporting warehouse your developers can work against the KIDUART REST API. Endpoints are versioned under a stable base path, access uses managed API keys with scoped permissions rather than a shared staff login, and every request is rate limited and logged.
What you get
- Versioned REST endpoints under a stable /api/v1 base path
- Managed API keys with per-scope permissions instead of a staff password
- Keys can be rotated or revoked without disturbing staff logins
- Published endpoint reference for your developers
- Rate limiting and request logging on every call
The connection, hop by hop
How REST API and webhooks actually works here
No hand-waving about being 'seamlessly integrated'. This is the path a single event takes, end to end.
Access requested
You tell us what the integration needs to read or write, and for which part of the school.
Scoped key issued
A key is issued with only those scopes a reporting job never gets permission to write records.
Developer builds
Your developer works against the versioned endpoints using the published reference.
Calls logged and limited
Requests are rate limited and recorded, so unusual usage is visible and a leaked key can be revoked.
Keys, data and the bill
Who holds the credentials
Keys are issued to your school and can be rotated or revoked by you at any time.
Where the data sits
Anything the key's scopes allow, and nothing else. Scope is the boundary, not trust.
Who gets billed
API access is part of your subscription, subject to fair-use rate limits.
Where it lands in the product
The modules this integration writes into
An integration is only useful if it writes into the module your staff already work in. These are the exact modules involved.
Setup, step by step
Connecting REST API and webhooks
Request API access for your school and describe the use case
We issue a scoped API key for that integration
Your developer reads the endpoint reference
Build and test against non-production data first
Go live, and rotate the key on your own schedule
What you need on your side
- A developer or vendor who will maintain the integration
- A clear scope for what the key is allowed to do
- An owner on your side for rotating keys when people change
Questions schools ask
REST API and webhooks, answered plainly
Can an API key be limited to read-only?
Yes. Keys are scoped, so a reporting integration does not need permission to write records.
What if a key is leaked?
Revoke it and issue a new one. Keys are managed objects, which is exactly why they are better than sharing a staff login.
Can we subscribe our own endpoint to school events?
Not yet. Incoming webhooks from payment and messaging providers are handled today; school-subscribed outbound webhooks are still on the roadmap, and we will not pretend otherwise.
Also in files, data and developer access
Related integrations
Cloud document storage
Store admission documents, certificates and staff files in managed cloud storage instead of a shared drive.
Excel and CSV exports
Take any list or report out as Excel, CSV or PDF for your accountant, trust office or board submission.
Portal usage analytics
Planned: adoption analytics for the parent and student portals, built without profiling children.
See REST API and webhooks in a live demo
We will run the connection on screen with your own scenario your fee book, your parent groups, your school accounts.
30-minute walkthrough
Booked around your school hours
Run on your own data
Your fee heads, classes and staff roles
No card, no lock-in
Nothing is charged to see the product