PadelOS brengt gegevens over spelers, trainers, lessen, locaties, banen, organisaties, facturen en betalingen samen binnen één digitale werkomgeving. Om deze informatie veilig en efficiënt te kunnen uitwisselen, is een betrouwbare technische verbindingslaag nodig.
De module PadelOS API, Integraties & Import/Export vormt deze verbindingslaag. De module maakt het mogelijk om gegevens gecontroleerd uit te wisselen tussen PadelOS, Google Sheets, agenda’s, documentopslag, communicatiekanalen, betaalproviders, boekhoudsystemen en toekomstige sportplatforms.
De API is niet alleen bedoeld voor ontwikkelaars. Ook administrators, databeheerders, clubs en padelscholen moeten zonder programmeerkennis bestanden kunnen importeren, gegevens kunnen controleren en betrouwbare exports kunnen maken.
PadelOS kiest daarom voor een combinatie van:
gestandaardiseerde API-endpoints;
beheerde import- en exportprocessen;
validatie en duplicaatcontrole;
logging en herstelmogelijkheden;
veilige authenticatie en autorisatie;
duidelijke technische documentatie;
uitbreidbare koppelingen met externe systemen.
De huidige technische basis bestaat uit Google Apps Script, Google Sheets en een centrale Registry- en CRUD-architectuur. Deze basis wordt stapsgewijs uitgebouwd tot een professionele API-laag voor het toekomstige multi-tenantplatform CAMTESI.
De visie van PadelOS is dat gegevens één keer zorgvuldig worden vastgelegd en daarna veilig kunnen worden gebruikt binnen alle bevoegde modules en systemen.
Een spelersrecord dat via een CSV-import wordt toegevoegd, moet bijvoorbeeld niet opnieuw handmatig worden ingevoerd voor planning, aanwezigheid, facturatie of communicatie. De gegevens worden centraal verwerkt, gevalideerd en via unieke identificaties gekoppeld aan de juiste profielen en processen.
De integratiearchitectuur wordt ontwikkeld vanuit vijf uitgangspunten:
Eén betrouwbare gegevensbasis
PadelOS voorkomt dat iedere module of koppeling een eigen, afwijkende kopie van dezelfde gegevens gebruikt.
Open waar mogelijk, afgeschermd waar noodzakelijk
Technische koppelingen moeten goed gedocumenteerd en uitbreidbaar zijn, maar persoonsgegevens en financiële gegevens blijven streng beveiligd.
Configuratie boven maatwerk
Nieuwe tabellen, velden en relaties worden bij voorkeur via registries en configuraties aangesloten.
Controleerbare gegevensuitwisseling
Elke import, export en API-mutatie moet kunnen worden gecontroleerd en waar nodig hersteld.
Geleidelijke professionalisering
De huidige Apps Script-oplossingen dienen als ontwikkel- en testomgeving. Voor grootschalig professioneel gebruik zijn aanvullende cloudinfrastructuur, beveiliging, monitoring en tenantisolatie noodzakelijk.
Padelscholen, trainers, clubs en organisaties gebruiken vaak meerdere losstaande systemen. Spelers staan in spreadsheets, baanreserveringen in een apart platform, lessen in agenda’s, betalingen bij een betaalprovider en documenten in verschillende opslaglocaties.
Hierdoor ontstaan risico’s zoals:
dubbele personen en contactgegevens;
verschillende schrijfwijzen van namen;
verouderde telefoonnummers en e-mailadressen;
ontbrekende relaties tussen speler, trainer, les en factuur;
handmatige kopieerfouten;
onduidelijkheid over de meest actuele versie;
exports zonder uniforme kolommen;
onvoldoende controle op persoonsgegevens;
moeilijk reproduceerbare imports;
afhankelijkheid van één medewerker of spreadsheet.
PadelOS lost dit op door import, export en technische koppelingen onderdeel te maken van de centrale gegevensarchitectuur. Externe gegevens worden niet zomaar in een tabel geplaatst, maar doorlopen een gecontroleerd proces van herkenning, mapping, validatie, vergelijking, verwerking en registratie.
De module is ontwikkeld voor verschillende professionele gebruikersgroepen.
Ontwikkelaars kunnen via gedocumenteerde endpoints gegevens opvragen en, wanneer zij daarvoor bevoegd zijn, records aanmaken of wijzigen.
Integratiespecialisten ontwerpen koppelingen tussen PadelOS en externe agenda-, communicatie-, betaal-, boekhoud- en sportplatforms.
Databeheerders beheren imports, kolomkoppelingen, gegevenskwaliteit, duplicaten, foutmeldingen en correcties.
Administrators bepalen welke systemen toegang krijgen, welke gegevens mogen worden verwerkt en welke gebruikers import- of exportrechten ontvangen.
Trainers en planners kunnen bijvoorbeeld lesplanningen, deelnemerslijsten, aanwezigheidsgegevens en lesdocumenten exporteren of agenda-informatie synchroniseren.
Organisaties kunnen hun bestaande spelers-, leden-, trainer-, locatie- en baanbestanden gecontroleerd naar PadelOS migreren.
Externe leveranciers kunnen op termijn een gecertificeerde koppeling ontwikkelen op basis van de PadelOS API-specificaties en beveiligingsvoorwaarden.
De module omvat onder meer:
API-verzoeken voor tabellen, velden en records;
endpoints voor lezen, aanmaken, wijzigen en verwijderen;
filters, zoekopdrachten, sortering en paginering;
CSV-, JSON- en TXT-import;
CSV-, JSON-, TXT- en PDF-export;
automatische en handmatige kolomkoppeling;
importpreview voordat gegevens worden opgeslagen;
controle van verplichte velden;
formaat- en datatypevalidatie;
herkenning van mogelijke duplicaten;
importlogs met resultaten en foutmeldingen;
exportprofielen voor verschillende doelgroepen;
herstel en terugdraaien van importbatches;
autorisatie per rol, module, tabel en handeling;
versiebeheer van endpoints;
webhookverwerking;
technische documentatie;
test- en productieomgevingen;
monitoring, logging en foutafhandeling.
Niet alle functies zijn al volledig als productievoorziening beschikbaar. De architectuur maakt daarom steeds onderscheid tussen huidige tests, tijdelijke oplossingen, functies in ontwikkeling en toekomstige integraties.
De API wordt logisch verdeeld in functionele domeinen. Ieder domein kan eigen endpoints en toegangsvoorwaarden krijgen.
Voorbeelden van domeinen zijn:
accounts en gebruikers;
personen en profielen;
spelers;
trainers;
organisaties;
clubs;
locaties en banen;
teams en trainingsgroepen;
lessen en lesreeksen;
planning en aanwezigheid;
lesvoorbereiding en oefeningen;
facturen en betalingen;
contacten en communicatie;
bestanden en documenten;
rapportages;
registries en metadata;
imports en exports;
auditlogs en systeembeheer.
Een toekomstige API-structuur kan bijvoorbeeld werken met versienummers in het adres:
/api/v1/personen
/api/v1/spelers
/api/v1/trainers
/api/v1/organisaties
/api/v1/locaties
/api/v1/banen
/api/v1/lessen
/api/v1/planning
/api/v1/facturen
/api/v1/betalingen
/api/v1/imports
/api/v1/exports
Deze adressen zijn een architectuurvoorstel. Ze mogen niet automatisch worden beschouwd als publiek beschikbare productie-endpoints.
De huidige Apps Script-router ondersteunt al bewerkingen voor:
het opvragen van beschikbare tabellen;
het opvragen van headers van een geselecteerde tabel;
het lezen van rijen;
het opslaan van nieuwe rijen;
het wijzigen van bestaande rijen;
het verwijderen van rijen.
Deze functies vormen de technische basis voor verdere standaardisering.
API-verzoeken worden opgebouwd uit een methode, endpoint, authenticatie, parameters en eventueel een gegevensobject.
Gebruikelijke methoden zijn:
Methode
Functie
GET
Gegevens lezen
POST
Een nieuw record of proces aanmaken
PUT
Een volledig record vervangen
PATCH
Geselecteerde velden wijzigen
DELETE
Een record verwijderen of deactiveren
Een verzoek voor een nieuwe speler kan conceptueel bijvoorbeeld de volgende gegevens bevatten:
{
"voornaam": "SPELER 1",
"achternaam": "",
"email": "speler1@example.nl",
"telefoon": "0031612345678",
"niveau": "8",
"status": "ACTIEF"
}
Een uniform antwoord bevat bij voorkeur:
{
"success": true,
"data": {
"spelerId": "SPELER-000001"
},
"message": "Speler succesvol aangemaakt",
"requestId": "REQ-20260730-000001",
"timestamp": "2026-07-30T08:00:00+02:00"
}
Bij een fout wordt geen ongestructureerde technische melding teruggegeven, maar een herkenbaar foutobject:
{
"success": false,
"error": {
"code": "VALIDATION_ERROR",
"message": "Het veld Email bevat geen geldig e-mailadres",
"field": "email"
},
"requestId": "REQ-20260730-000002"
}
Een requestId maakt het mogelijk om een probleem terug te vinden in de technische logs zonder onnodig persoonsgegevens in foutmeldingen op te nemen.
Niet iedere gebruiker of externe applicatie mag alle gegevens opvragen. PadelOS combineert daarom authenticatie met fijnmazige autorisatie.
Authenticatie stelt vast wie of welk systeem een verzoek uitvoert. Mogelijke methoden zijn:
beveiligde gebruikerssessies;
tijdelijke toegangstokens;
OAuth-gebaseerde toestemming;
API-sleutels voor beperkte technische toepassingen;
serviceaccounts voor systeemkoppelingen;
webhookhandtekeningen voor het controleren van afzenders.
Autorisatie bepaalt vervolgens wat de geauthenticeerde gebruiker of applicatie mag doen.
Rechten kunnen worden ingesteld op:
tenant of werkruimte;
organisatie;
module;
tabel;
veld;
record;
handeling;
doel van de verwerking.
Een trainer kan bijvoorbeeld alleen de eigen lessen en toegewezen spelers bekijken. Een clubmanager kan gegevens beheren binnen de eigen club. Een softwarepartner kan uitsluitend toegang krijgen tot de endpoints die voor de koppeling noodzakelijk zijn.
Geheime sleutels en tokens mogen nooit:
in openbare HTML-code worden geplaatst;
in Google Sites-pagina’s worden gepubliceerd;
in exports of screenshots worden opgenomen;
onbeveiligd per e-mail of chat worden gedeeld;
rechtstreeks in broncode worden vastgelegd.
Voor professioneel gebruik zijn sleutelbeheer, periodieke rotatie, intrekking, versleuteling en toegangslogging noodzakelijk.
PadelOS kent als centrale rollen:
Administrator;
Manager;
Trainer;
Speler;
Viewer.
Voor API, import en export zijn aanvullende rechten nodig. Voorbeelden zijn:
API_LEZEN;
API_SCHRIJVEN;
IMPORT_STARTEN;
IMPORT_GOEDKEUREN;
IMPORT_HERSTELLEN;
EXPORT_MAKEN;
EXPORT_PERSOONSGEGEVENS;
EXPORT_FINANCIEEL;
KOPPELINGEN_BEHEREN;
WEBHOOKS_BEHEREN;
API_LOGS_BEKIJKEN.
Het bezit van een algemene rol geeft niet automatisch recht op iedere export. Een trainer kan bijvoorbeeld een eigen leskaart exporteren, maar niet zonder meer een volledig bestand met alle spelers, contactgegevens en financiële informatie downloaden.
Voor gevoelige handelingen kan een vierogenprincipe worden toegepast. Daarbij voert één medewerker de import uit en keurt een andere bevoegde medewerker de definitieve verwerking goed.
De PadelOS API wordt verbonden met de centrale Registry-architectuur.
Beschrijft welke functionele modules beschikbaar zijn en welke API-functies bij een module horen.
Bevat de definities van tabellen zoals PERSONEN, SPELERS, TRAINERS, ORGANISATIES, LOCATIES, BANEN, LESSEN, FACTUREN en BETALINGEN.
Legt per veld vast:
de technische veldnaam;
het datatype;
de zichtbare naam;
of het veld verplicht is;
welke validatieregels gelden;
of het veld importeerbaar of exporteerbaar is;
welke rollen het veld mogen zien of wijzigen.
Beschrijft relaties tussen records. Hierdoor kan een importproces herkennen dat een spelerprofiel moet worden gekoppeld aan een bestaande persoon, organisatie, lesgroep of gebruiker.
Bevat aanvullende kenmerken, versies, statussen, broninformatie en verwerkingsregels.
Bepaalt welke bewerkingen voor een tabel of module beschikbaar zijn: aanmaken, lezen, wijzigen, verwijderen, archiveren of herstellen.
Door deze registries te gebruiken hoeft niet iedere koppeling afzonderlijk te worden geprogrammeerd. De API kan definities, validaties en rechten centraal uitlezen en toepassen.
PadelOS ondersteunt stapsgewijze import van verschillende bestandsformaten.
CSV is geschikt voor tabelgegevens zoals spelerslijsten, trainers, organisaties, locaties, banen, tarieven en planningen. Het systeem moet rekening houden met:
komma’s of puntkomma’s als scheidingsteken;
verschillende tekencoderingen;
Nederlandse en internationale datumnotaties;
getallen met komma’s of punten;
telefoonnummers met +31, 0031 of een nationale notatie;
lege velden;
aanhalingstekens en regeleinden in tekstvelden.
JSON is geschikt voor gestructureerde gegevens en systeemkoppelingen. Geneste objecten worden niet automatisch rechtstreeks in een platte tabel geplaatst. Eerst wordt bepaald hoe objecten, lijsten en relaties naar de PadelOS-tabellen worden vertaald.
TXT-import kan worden gebruikt voor eenvoudige lijsten, configuraties, woordenlijsten, lesinhoud of bestanden met een herkenbare scheiding. De gebruiker selecteert of bevestigt hoe regels en velden moeten worden geïnterpreteerd.
PDF is primair een uitvoer- en documentformaat. Het automatisch importeren van gegevens uit PDF-bestanden vereist aparte extractie- en herkenningstechnieken en valt niet onder de standaard tabelimport.
Externe bestanden gebruiken niet altijd dezelfde kolomnamen als PadelOS. Een bestand kan bijvoorbeeld E-mail, Mailadres of EmailAddress gebruiken, terwijl het centrale veld in PadelOS EMAIL heet.
De importwizard toont daarom een kolomkoppeling:
Bronkolom
PadelOS-veld
Actie
Voornaam
VOORNAAM
Importeren
Tussenvoegsel
TUSSENVOEGSEL
Importeren
Achternaam
ACHTERNAAM
Importeren
Importeren en valideren
Mobiel
TELEFOON
Normaliseren
Ranking
NIVEAU
Controleren
Onbekende kolom
Geen koppeling
Overslaan of nieuw veld voorstellen
De gebruiker krijgt vóór verwerking een preview met:
het aantal gelezen regels;
herkende kolommen;
ontbrekende verplichte velden;
geldige records;
records met waarschuwingen;
afgekeurde records;
mogelijke duplicaten;
nieuwe personen;
bestaande personen die worden hergebruikt;
nieuwe profielkoppelingen;
records die worden overgeslagen.
Pas na controle en bevestiging wordt een definitieve import uitgevoerd. Voor grotere of gevoelige imports kan goedkeuring door een administrator verplicht worden gesteld.
Elke import en API-mutatie wordt gecontroleerd op gegevenskwaliteit.
Mogelijke validaties zijn:
aanwezigheid van verplichte velden;
geldige e-mailstructuur;
normalisatie van telefoonnummers;
geldige datums en tijden;
toegestane statuswaarden;
geldige KNLTB-speelsterkte;
positieve bedragen en correcte valuta;
bestaande verwijzingen naar organisaties en locaties;
geldige unieke ID’s;
toegestane veldlengtes;
bescherming tegen schadelijke inhoud;
controle op onverwachte formules in spreadsheetimports.
Normalisatie zorgt ervoor dat vergelijkbare gegevens op dezelfde wijze worden opgeslagen. Voorbeelden zijn:
e-mailadressen in kleine letters;
spaties voor en na waarden verwijderen;
telefoonnummers naar één intern formaat omzetten;
statussen naar vaste waarden zoals ACTIEF, INACTIEF of GEARCHIVEERD vertalen;
datums naar een uniforme technische notatie converteren;
landcodes en adressen standaardiseren.
De oorspronkelijke bronwaarde kan in de importlog worden bewaard wanneer dit nodig is voor controle, zonder dat deze onbeperkt beschikbaar blijft.
Duplicaatcontrole is essentieel voor de relatie tussen:
PERSONEN;
SPELERS;
TRAINERS;
GEBRUIKERS;
PERSOON_PROFIELEN;
GEBRUIKER_PERSONEN;
ORGANISATIES;
ORGANISATIE_PERSONEN;
CLUBCONTACTEN;
CONTACTS.
Een speler en een trainer kunnen dezelfde persoon zijn. Die persoon hoort daarom niet twee keer in PERSONEN te worden aangemaakt. In plaats daarvan krijgt de bestaande persoon meerdere profielen en rollen.
Mogelijke herkenningskenmerken zijn:
centraal PersoonID;
e-mailadres;
genormaliseerd telefoonnummer;
bondsnummer;
externe systeem-ID;
combinatie van voornaam, achternaam en geboortedatum;
combinatie van naam en organisatie.
Automatische herkenning mag niet uitsluitend op een zwakke overeenkomst vertrouwen. Twee personen kunnen dezelfde naam hebben en één persoon kan meerdere e-mailadressen gebruiken.
Mogelijke uitkomsten van duplicaatcontrole zijn:
nieuw record aanmaken;
bestaand record hergebruiken;
nieuw profiel aan bestaande persoon koppelen;
gegevens aanvullen;
ter beoordeling voorleggen;
record overslaan;
import blokkeren vanwege een conflict.
Besluiten over samenvoegen worden gelogd, zodat later zichtbaar blijft welke records, bronnen en gebruikers bij de beslissing betrokken waren.
Exports worden afgestemd op het gebruiksdoel.
Geschikt voor spreadsheetanalyse, gegevensoverdracht en gecontroleerde migraties.
Geschikt voor systeemkoppelingen, back-ups, technische analyses en overdracht met behoud van structuur en metadata.
Geschikt voor leesbare overzichten, lesvoorbereidingen, eenvoudige archieven en communicatie via tekstkanalen.
Geschikt voor:
leskaarten;
oefenkaarten;
planningen;
aanwezigheidslijsten;
offertes;
facturen;
rapportages;
evaluaties;
overeenkomsten;
managementoverzichten.
Exportprofielen bepalen welke velden worden opgenomen. Een spelerslijst voor een trainer bevat bijvoorbeeld andere informatie dan een financiële export voor de boekhouder.
Iedere export kan metadata bevatten, zoals:
exportdatum;
uitvoerende gebruiker;
organisatie of tenant;
geselecteerde filters;
gegevensperiode;
exportprofiel;
systeemversie;
waarschuwing over vertrouwelijkheid.
Gevoelige exports kunnen worden voorzien van een beperkte geldigheidsduur, aanvullende toestemming, watermerk, versleuteling of beveiligde opslag.
Iedere import krijgt een uniek importbatchnummer. De importlog registreert minimaal:
bestandsnaam;
bestandstype;
start- en eindtijd;
uitvoerende gebruiker;
doelorganisatie;
doeltabel of module;
aantal gelezen records;
aantal aangemaakte records;
aantal gewijzigde records;
aantal overgeslagen records;
aantal fouten;
waarschuwingen;
gebruikte kolomkoppeling;
validatieversie;
status van de import.
Op recordniveau kan worden vastgelegd:
bronregel;
bron-ID;
doelrecord-ID;
uitgevoerde actie;
foutcode;
waarschuwing;
vorige waarde;
nieuwe waarde.
Voor herstel zijn verschillende niveaus mogelijk:
correctie van een afzonderlijk record;
opnieuw uitvoeren van alleen afgekeurde regels;
terugdraaien van een importbatch;
herstellen vanuit een momentopname;
herstellen vanuit een beveiligde back-up.
Terugdraaien is alleen veilig wanneer afhankelijkheden worden gecontroleerd. Een geïmporteerde speler kan na de import al aan lessen, facturen of betalingen zijn gekoppeld. In zo’n situatie kan archiveren veiliger zijn dan fysiek verwijderen.
De huidige ontwikkelomgeving gebruikt Google Apps Script en Google Sheets. Daardoor zijn Google-diensten een logisch startpunt voor integraties.
De koppeling met Google Sheets wordt al gebruikt en getest voor:
het opvragen van tabbladen;
het lezen van headers;
het lezen van rijen;
het toevoegen van records;
het wijzigen van records;
het verwijderen van records;
het dynamisch verwerken van tabellen via Registry en CRUD.
Voor professioneel gebruik zijn aanvullende maatregelen nodig voor gelijktijdige mutaties, limieten, transacties, back-ups en toegangsbeheer.
Een test met een aparte PadelSchool-agenda is uitgevoerd. Toekomstige functies kunnen bestaan uit:
lessen als agenda-afspraken;
agenda’s per trainer;
team- en spelersagenda’s;
wijzigingsmeldingen;
beschikbaarheidscontrole;
annuleringen;
vervangende trainers;
reistijdbuffers;
synchronisatie van externe wijzigingen.
Definitieve synchronisatieregels, conflictafhandeling en toestemmingen moeten nog verder worden ontworpen en getest.
Google Drive kan worden gebruikt voor het opslaan van exports, facturen, leskaarten en rapportages. Hiervoor moeten onder meer bewaartermijnen, mappenstructuren, eigenaarschap en deelrechten worden vastgelegd.
Een koppeling wordt pas als productiegeschikt beschouwd nadat beveiliging, foutafhandeling, logging, limieten en toestemming aantoonbaar zijn getest.
PadelOS onderzoekt koppelingen met verschillende soorten systemen.
Mogelijke toepassingen zijn:
betaalverzoeken;
betaallinks;
betaalstatussen;
restituties;
abonnementen;
uitbetalingen;
webhookmeldingen.
Stripe en andere betaalproviders kunnen als mogelijke integratie worden onderzocht. Dit betekent niet dat een specifieke provider al definitief of volledig beschikbaar is.
Een boekhoudkoppeling kan facturen, betalingen, btw-gegevens, debiteuren en grootboekinformatie uitwisselen. De fiscale en administratieve verantwoordelijkheid blijft bij de organisatie en haar bevoegde boekhouder.
Mogelijke koppelingen zijn:
e-mail;
WhatsApp-links;
sms-diensten;
pushmeldingen;
nieuwsbrieven;
interne notificaties.
Automatische verzending vereist expliciete toestemming, juiste ontvangerselectie, opt-outmogelijkheden en controle op communicatiedoelen.
Toekomstige koppelingen kunnen betrekking hebben op:
ledenadministraties;
competitieplatforms;
rating- en niveausystemen;
baanreserveringssystemen;
toernooiplatforms;
opleidings- en certificeringssystemen.
Voor iedere koppeling moet eerst worden onderzocht:
of een officiële API beschikbaar is;
welke gebruiksvoorwaarden gelden;
welke toestemming nodig is;
welke persoonsgegevens worden verwerkt;
wie verantwoordelijk is voor fouten;
hoe wijzigingen en beëindiging worden afgehandeld.
De technische basis van PadelOS is al aantoonbaar getest voor een aantal kernhandelingen.
Google Apps Script als backend;
Google Sheets als huidige gegevensopslag;
ophalen van ongeveer honderd tabellen;
uitlezen van dynamische headers;
uitlezen van records;
centrale CRUD-functies;
toevoegen, wijzigen en verwijderen van rijen;
mobiele tabel- en kaartweergave;
Registry-opzet voor modules, tabellen, velden en relaties;
dry-run van de migratie van spelers en trainers naar centrale personen en profielen;
CSV-, JSON- en TXT als voorziene import- en exportformaten;
exports van lesinhoud en gegevensoverzichten;
een eerste Google Calendar-test.
uniforme publieke API-specificatie;
volledige authenticatie met veilige tokens;
rechten per tenant, endpoint, tabel, record en veld;
algemene importwizard;
herbruikbare mappingprofielen;
geautomatiseerde duplicaatcontrole;
importbatchherstel;
paginering en geavanceerde filters;
rate limiting;
webhookbeheer;
centrale API-documentatie;
monitoring en automatische waarschuwingen;
gescheiden test-, acceptatie- en productieomgevingen.
definitieve Google Calendar-synchronisatie;
Google Drive-documentbeheer;
betaalproviderintegraties;
boekhoudkoppelingen;
automatische communicatiekanalen;
externe baanreserveringssystemen;
bonds-, rating- en sportplatforms;
internationale gegevensuitwisseling.
Fase 1 – Stabiliseren
Bestaande Apps Script-endpoints uniform maken en voorzien van gestandaardiseerde antwoorden en foutcodes.
Fase 2 – Importcentrum
Bestandsupload, kolomkoppeling, preview, validatie, dry-run en importlogs implementeren.
Fase 3 – Centrale autorisatie
Rechten koppelen aan gebruikers, organisaties, modules, tabellen en handelingen.
Fase 4 – Exportcentrum
Herbruikbare exportprofielen voor CSV, JSON, TXT en PDF ontwikkelen.
Fase 5 – Integratiebeheer
Externe verbindingen, sleutels, scopes, webhooks, monitoring en intrekking centraal beheren.
Fase 6 – CAMTESI-cloudarchitectuur
De verbindingslaag migreren naar een schaalbare, geïsoleerde en professioneel beheerde multi-tenantomgeving.
PadelOS wordt ontworpen om later te functioneren binnen CAMTESI: Cloud Architecture & Multi-Tenant Engine – System International. Binnen deze architectuur kan iedere club, padelschool, vereniging, stichting of onderneming een afzonderlijke tenant of werkruimte krijgen.
Elke API-aanvraag moet dan niet alleen aan een gebruiker, maar ook aan de juiste tenant worden gekoppeld. Hierdoor kunnen gegevens van verschillende organisaties technisch en organisatorisch van elkaar worden gescheiden.
De toekomstige architectuur moet onder meer voorzien in:
tenant-ID’s in verzoeken en records;
gegevensisolatie;
organisatiespecifieke rollen;
eigen integratie-instellingen;
eigen import- en exportprofielen;
gescheiden API-sleutels;
tenantgebonden auditlogs;
verwerkingslimieten;
bewaartermijnen;
back-up- en herstelbeleid;
regionale gegevensopslag;
versie- en wijzigingsbeheer;
beëindiging en veilige gegevensoverdracht.
Een professionele integratie bestaat niet alleen uit een werkende technische verbinding. Er zijn ook duidelijke afspraken nodig over:
eigenaarschap van gegevens;
verwerkingsverantwoordelijkheid;
toestemming en doelbinding;
AVG en dataminimalisatie;
beveiligingsincidenten;
beschikbaarheid en ondersteuning;
wijziging van API-versies;
aansprakelijkheid;
verwijdering en archivering;
beëindiging van de samenwerking.
PadelOS wil hiermee doorgroeien van een verzameling handige koppelingen naar een controleerbaar integratieplatform. API’s, imports en exports worden geen losse technische hulpmiddelen, maar beheerde onderdelen van één samenhangende gegevensarchitectuur.
Zo ontstaat een veilige verbindingslaag waarmee trainers, spelers, clubs, organisaties en softwarepartners kunnen samenwerken zonder de controle over gegevens, rechten en verantwoordelijkheden te verliezen.