FlowRunner
PricingContact
Theme
Start Free

Kinderpedia

Education & LMS

Connect AI agents to Kinderpedia, a school and kindergarten management platform. Agents create students and parents and update student records, manage groups, families, and custom fields, and react to new enrollments so student records stay in sync with the rest of your stack.

Verified 1 trigger 16 actions API key available
New Student fires when a child is enrolled at the configured school
Agent reads the student record with Include Context to pull the group, family, and parents in one pass
Agent checks the record against the signed enrollment paperwork for required fields
Agent confirms the family assignment resolves to an existing family rather than creating a new one
Agent calls Set Custom Field Value to record the enrollment-specific attributes the school tracks
The school administrator confirms guardian identities and pickup authorization before any guardian account is created

What This Integration Enables

Kinderpedia is a school and kindergarten management platform, so every record this connector touches describes a child, a family, or the adults authorized to act for them. FlowRunner agents can list and search students, create and update student records, read groups and families, create parent and guardian accounts, and manage the custom field definitions and values a school uses to track anything the standard record does not cover. A polling trigger fires when a new student is enrolled.

The point of connecting a school system to an orchestration as a service layer is not to move children's data around more freely. It is to stop the same details being retyped into four places by an administrator who is also answering the phone. The right posture with this connector is narrow: read what a flow needs, write only what the school has already decided, and route output only to destinations the school has approved for student and family information. FlowRunner does not certify this connector, Kinderpedia, or your configuration against any data protection scheme, and nothing on this page should be read as a compliance claim. Which destinations are appropriate, what may leave the school system, and under what lawful basis are decisions the school makes with its own advisors. What the platform contributes is that those decisions are enforceable as steps in a flow, with the record of who approved each one.

Without FlowRunner

Enrollment data entered repeatedly The same child and family details are typed into the school system, the billing sheet, and the class list
Guardian details drift A guardian added during a busy intake week never gets checked against the paperwork
Sibling records split A family created twice leaves brothers and sisters in separate family groups

With FlowRunner

One enrollment, one write The student record is created once and downstream systems read from it
Guardian authorization confirmed by a person Pickup permission is set only after an administrator checks it against the signed form
Families resolved before creation The agent looks up the existing family before it ever asks for a new one

Use Case Scenarios

Enrollment intake reconciled against the record

An admissions form is completed and the child is enrolled. New Student fires with the full student record. The agent reads the record with Include Context so it has the group, family, and parent relationships in one response, compares the captured fields against the enrollment submission, and flags anything that does not match: a birthdate in the wrong format, a missing group assignment, a family that does not exist yet. The clean records are completed with Set Custom Field Value for the school's own attributes. The mismatches go to the administrator as an exception list rather than being guessed at.

Class rosters and group changes

At the start of a term, children move between groups. The agent calls Search Students filtered by enrollment status and group to build the current roster, calls List Groups and Get Group to resolve names, and calls Update Student for each confirmed move. Because Update Student changes only the fields supplied, the rest of the child's profile is untouched. The agent produces the before and after roster for the head teacher to check, and applies only the moves that were approved.

Keeping custom fields honest

Schools track things the standard record does not hold: dietary requirements, medical notes, consent flags, transport arrangements. The agent calls List Custom Field Definitions to discover the attribute IDs configured for students and parents, then uses Set Custom Field Value, Update Custom Field Value, and Delete Custom Field Value to keep those values current as the school's own records change. Values with safeguarding or medical significance are never written from an unattended feed; the agent stages the change and the administrator confirms it.

Human-in-Loop Highlight

Create Parent carries a field that has nothing in common with the rest of the connector: the pickup permission, which controls whether that guardian is authorized to collect children. Everything else on this API is administrative. That one boolean is a safeguarding decision, and it is arriving from an intake form filled in by whoever happened to be sitting at a keyboard. The same call carries two more traps. Only one parent per family may be the main family account, and passing a Family ID of 0 creates a new family rather than attaching to an existing one, which is how two siblings end up in two different families and a guardian ends up attached to only one of them. So the agent does not create guardian accounts on its own. It resolves the family with List Families and Get Family, prepares the guardian record, and stops with a specific question for the school administrator: "Enrollment for Sofia M. lists a second guardian, Andrei M., requesting pickup authorization. The form does not match an existing family, so creating this guardian will also create a new family and separate Sofia from her brother's record. Confirm the guardian, the pickup authorization, and the family to attach to." The administrator answers with the signed paperwork in front of them. The agent then creates exactly what was confirmed, and logs who confirmed it.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via preferred channel
Human decides
Agent resumes with decision

Agent Capabilities

16 actions

Students

5
  • List Students Returns a paginated list of students enrolled at the configured school. Include Context embeds the current group, parents, family, or custom fields in each record so a flow does not have to make follow-up calls.
  • Get Student Retrieves one student by ID with profile details and enrollment status, with the same Include Context option.
  • Create Student Enrolls a student and assigns them to a family and a group. Passing a Family ID of 0 creates a new family, which is a decision worth confirming rather than defaulting to.
  • Update Student Updates selected fields on an existing student. Fields not supplied are left untouched, so a targeted correction cannot overwrite unrelated data.
  • Search Students Searches students filtered by enrollment status and optionally by group. Used to build rosters and to check whether a child is already enrolled before creating a record.

Parents and Guardians

3
  • List Parents Returns a paginated list of parent and guardian accounts at the school.
  • Get Parent Retrieves one parent or guardian account by ID with name, email, and family relationship details.
  • Create Parent Creates a guardian account and attaches it to a family with a role, including the pickup permission that authorizes collecting children. This is the highest-consequence write in the connector and the one that belongs behind a person.

Groups and Families

4
  • List Groups Returns the groups, meaning classes, at the school.
  • Get Group Retrieves one group by ID with its name and details. Used to resolve a class before assigning a child to it.
  • List Families Returns the families at the school, each grouping the students and guardian accounts that belong together.
  • Get Family Retrieves one family by ID with its members. Used to attach a new guardian or sibling to the family that already exists.

Custom Fields

4
  • List Custom Field Definitions Returns the custom field definitions configured for an entity type, each with its attribute ID and label. Used to discover what the school tracks before writing any value.
  • Set Custom Field Value Sets a custom field value on a specific student or parent record where none exists yet.
  • Update Custom Field Value Changes an existing custom field value on a specific entity.
  • Delete Custom Field Value Removes a custom field value from an entity. Used when a consent or arrangement is withdrawn and the school wants the value gone rather than blanked.

Triggers

1 triggers

Event Triggers

1
  • New Student Fires when a new student is enrolled at the configured school, emitting the full student record. The first polling cycle records the students already present without firing, so existing children are never replayed into a flow. Include Context embeds related data in each emitted student, the polling interval is configurable down to thirty seconds, and each cycle inspects the most recent fifty students. Used to start enrollment intake, roster updates, and record reconciliation the moment a child is added.

Frequently Asked Questions

What can FlowRunner do with Kinderpedia?

FlowRunner agents can run List Students, Get Student, and Create Student in Kinderpedia, plus 13 more actions.

Does connecting Kinderpedia to FlowRunner require OAuth?

No. Kinderpedia connects to FlowRunner with an API key, no OAuth flow required.

Can Kinderpedia trigger a FlowRunner workflow automatically?

Yes. Kinderpedia supports 1 trigger that can start a FlowRunner workflow automatically.

Start building with Kinderpedia

$100 in credits. No card required. Connect in minutes.