Prompturn

Open aan beide kanten

Er zitten zo’n honderdtwintig routes in dit product en geen ervan is de publieke. Die veranderen van vorm telkens een scherm dat doet. Een sleutelhouder kun je niet herdeployen, dus de publieke API is klein, geversioneerd en gewoon.

Naar Excel, uit een bestand, en een URL die leads maakt.

Een tabel naar Excel geëxporteerd vanuit zijn eigen kop, rijen geplakt uit een spreadsheet en gekoppeld, en een regel die alles wat naar /website wordt gepost in een lead verandert.

Opgenomen in de demowerkruimte waarmee elke proefperiode begint. Zonder geluid.

De tabellen die jij maakte, zijn de API

Een tabel die je vanochtend met een prompt maakte, is vanmiddag aanspreekbaar, onder haar eigen naam, met haar eigen kolommen. Er is geen registratiestap, want een registratiestap is iets om te vergeten.

Het OpenAPI-document wordt per sleutel gegenereerd uit de tabellen die die sleutel mag zien, deels omdat een document dat tabellen opsomt waar je een 403 op krijgt een document is dat liegt, en deels omdat een tabel genaamd “Kandidaten herstructurering” er één is waarvan niemand buiten HR mag weten dat ze bestaat.

  • Volledige CRUD: lijsten met filters, sortering, zoeken en paginering; lezen; aanmaken; wijzigen; verwijderen naar de prullenbak
  • Enkel bearer-sleutels, nooit een cookie en nooit een sleutel in een querystring
  • Elke lees- en schrijfactie gaat door dezelfde rechtencontroles als de browser
  • Een rij die je niet mag lezen en een rij die niet bestaat geven allebei 404
  • Een limiet per sleutel, zodat één op hol geslagen integratie een rem is en geen storing
GET /api/v1/machines?filter=locatie:eq:214&sort=onderhoud:asc
Authorization: Bearer …  — een sleutel gebonden aan een persoon
Dezelfde rechten, diepten, business units en kolombeveiliging
200 — 18 rijen, gepagineerd, met de kolommen die deze sleutel mag lezen
GET /api/v1/openapi.json beschrijft het geheel, voor deze sleutel
Machines · API v1 · lezen

Alles waarmee het verbindt

Elk hiervan is een beslissing, geen vinkje. Waar we een gangbare aanpak weigerden, staat de reden erbij.

Machines die ermee praten

  • REST-API met versie op /api/v1, volledige CRUD
  • OpenAPI-document per sleutel gegenereerd uit je eigen tabellen
  • API-sleutels gebonden aan een persoon, zodat het auditspoor iemand blijft noemen
  • Inkomende webhooks die een flow starten, één eindpunt per flow
  • Uitgaande HTTP-stappen met SSRF-bescherming
  • Limieten per sleutel, instelbaar

Mail

  • Koppel je eigen Outlook of Gmail: gedelegeerd, per persoon, nooit domeinbreed
  • Berichten komen op de tijdlijn van de klant: wie, wanneer, onderwerp, fragment, link
  • Berichtinhoud wordt nooit bewaard: een fragment volstaat om een bericht te herkennen
  • Versturen gaat via je eigen mailbox, dus het slaagt voor SPF en staat in je Verzonden items
  • Een mailbox van de installatie voor antwoorden, per werkruimte gerouteerd
  • SMTP-relay als terugval, met sjablonen

Identiteit

  • OIDC single sign-on tegen je eigen identiteitsprovider
  • Claim je e-maildomeinen; niemand daarbuiten komt binnen
  • Maak een account aan bij eerste aanmelding, of weiger het
  • SCIM 2.0, zodat je directory mensen aanmaakt en deactiveert
  • De factuurverantwoordelijke houdt altijd een wachtwoord, zodat een foute IdP-configuratie je niet buitensluit
  • Verificatie in twee stappen voor wie het wil

Bestanden en cijfers

  • Import uit Excel en CSV, met kolommen automatisch gekoppeld en fouten per rij getoond
  • Elk scherm exporteren naar CSV of Excel
  • Bijlagen op records, met een grootte- en ruimteplafond per werkruimte
  • Btw-nummers gecontroleerd bij de VIES-dienst van de Commissie, met het bewijs bewaard
  • Offertes en facturen als documenten, klaar om te printen of te versturen
  • Back-ups die je zelf neemt, downloadt en terugzet

Waar we nee zeiden, en waarom

Microsoft Graph en Google bieden allebei een manier om elke mailbox in een organisatie te lezen. Allebei geweigerd hier. Een CRM dat de mail van de gedelegeerd bestuurder kan lezen, is een CRM waar geen enkel securityteam voor tekent, en een privacyrisico dat wij dan voor altijd bezitten.

Eén koppeling per persoon, door henzelf gegeven, en de routes nemen nooit een gebruikers-id aan, ze gebruiken die van de sessie. Een beheerder die de mailbox van iemand anders koppelt of verwijdert, is iets wat dit niet kan.

  • Enkel gedelegeerde rechten, nooit applicatiebreed
  • Metadata, nooit de inhoud van berichten
  • Ophalen via de bestaande wachtrij, geen nieuw publiek eindpunt
  • De juridische pagina noemt Microsoft of Google alleen als je er één koppelde

Richt er iets op

Maak tijdens de proefperiode een sleutel aan, lees het gegenereerde OpenAPI-document, en kijk of het oppervlak past bij de integratie die je in gedachten hebt.