Concepten & Architectuur

English only

Structure Overview

Welcome to Pluvo's API documentation. This document provides an overview of the key concepts and underlying structure of the Pluvo platform. It is intended as a starting point for developers building integrations or synchronizing data with Pluvo.

Core Concepts

Users

Participants, trainers, planners, or managers — anyone who logs into Pluvo is a User. Users can contain additional data (via extraFields) and are linked to groups or roles.

Groups

Organizational units that group users. Groups determine access to trainings and can have their own settings and managers.

Trainings

A Training contains learning content, progress rules, and scheduling. What users see as a "learning journey" in the interface is called a Training in the API.

Offers & Enrollment (Offers & OfferEvents)

An Offer is the overarching enrollment offering. An OfferEvent is a specific entry point. Users enroll in an OfferEvent.

Portfolio & Results

A PortfolioItem stores evidence, achievements, or certificates. PortfolioReport is an advanced query for analyzing progress, scores, and time spent.

Modules & Courses

Within a Training you'll find Modules that contain e-learning content such as videos, theory, assignments, or external LTI modules.

Webhooks

Pluvo can push events to your system. Examples include USER_CREATED, TRAINING_FINISHED, and COURSE_FINISHED.

Architecture

The Pluvo API is built as a GraphQL API. Key features:

  • ✅ One endpoint, multiple types and queries
  • 📦 Structure based on object types (such as User, Training, Group, etc.)
  • 🧩 Many objects contain ref fields for external connections
  • 🔐 Webhooks contain HMAC security via headers
  • 📂 Files are provided via Pluvo's own file storage URLs

Interaction Flows

Example flows within Pluvo:

  • Create new user → invite → link to group → enroll in training
  • User completes course → certificate → portfolio item → webhook
  • External tool (via LTI) completed → score and time → portfolioReport

Recommended Patterns

  • Use updateOrCreateUser and updateExtraCategoryValues for robust synchronization.
  • Archive instead of deleting (archiveUsers, archiveOffers, etc.).
  • Use PortfolioReport for evaluation and monitoring purposes.
  • Avoid direct dependency on UI names; work with ref, id, and contentType.
Sluit melding