Robaws & AI

Onze visie

Bij Robaws geloven we dat je ERP geen ommuurde tuin mag zijn. Je offertes, projecten, artikels, klanten en planning zijn jouw data — en het waardevolste wat je in 2026 met data kan doen, is software, en steeds vaker AI, ermee laten werken voor jou.

Daarom is alles wat je in de Robaws-interface ziet, ook beschikbaar via onze publieke REST API (v2). AI-assistenten, agents en automatiseringstools kunnen vandaag al lezen van en schrijven naar je account, op een veilige manier en volledig onder jouw controle. We wachten niet op een magische "AI-knop" — de basis staat er al, en je kan er nu meteen op bouwen.

Na verloop van tijd lanceren we ook AI-native functies binnen Robaws zelf (offertes opstellen, projecten samenvatten, risico's signaleren, vragen beantwoorden over je pipeline). We rollen die bewust per use-case scenario uit in plaats van als een gimmick, zodat elke functie zijn plaats verdient. Tot dan — en naast die functies — is de API de deur naar alles.

⚠️ Let op: Deze gids is geschreven voor ontwikkelaars. Als termen als HTTP Basic auth, base64-gecodeerde credentials, idempotente PATCH-requests en merge-patch content types je niets zeggen, is dit het moment om hulp in te schakelen. Spring naar het einde — we verwijzen je door naar een partner die dit dagelijks doet.

Hoe AI verbindt met Robaws

De Robaws API is een standaard RESTful HTTPS-interface. Elke AI-tool, agent-framework of middleware die geauthenticeerde HTTP-requests kan versturen en JSON kan verwerken, kan ermee integreren. Er is geen proprietaire SDK om te installeren — als het HTTP spreekt, spreekt het Robaws.

Base host (altijd):

https://app.robaws.com

Alle endpoints bevinden zich onder /api/v2/. De volledige machine-leesbare OpenAPI-specificatie is hier gepubliceerd:

https://app.robaws.com/public/api-docs/robaws

Richt je LLM-tooling, code-generator of agent-framework op die spec en het kan elke beschikbare resource, methode en payload-schema zelf beschrijven.

Authenticatie

De API gebruikt HTTP Basic authentication over TLS. Je authenticeert met een API key en een API secret, samengevoegd als key:secret en base64-gecodeerd in een Authorization-header.

# De header is: 'Basic ' + base64("APIKEY:APISECRET")
curl -s https://app.robaws.com/api/v2/clients?limit=1 \
  -H "Authorization: Basic $(printf '%s' 'APIKEY:APISECRET' | base64)" \
  -H "Accept: application/json"

Een 200 OK bevestigt dat je credentials geldig zijn. Een 401 Unauthorized betekent dat het key/secret-paar fout of ingetrokken is. Behandel het secret als een wachtwoord: zet het nooit in client-side code, browser-apps of iets dat een eindgebruiker kan inspecteren. Bewaar het in een server-side secret manager of environment variable en roteer het als je vermoedt dat het gelekt is.

Een minimale read

curl -s https://app.robaws.com/api/v2/offers?limit=10 \
  -H "Authorization: Basic <base64 credentials>" \
  -H "Accept: application/json"

Een minimale write

curl -s -X POST https://app.robaws.com/api/v2/clients \
  -H "Authorization: Basic <base64 credentials>" \
  -H "Content-Type: application/json" \
  -d '{
        "name": "Demo Construction",
        "language": "nl",
        "currency": "EUR",
        "status": "prospect"
      }'

Records bijwerken (hier loopt het bij velen mis)

Gedeeltelijke updates gebruiken PATCH en vereisen een specifiek content type. Een gewone application/json-body wordt geweigerd met 415 Unsupported Media Type. Gebruik:

Content-Type: application/merge-patch+json

curl -s -X PATCH https://app.robaws.com/api/v2/offers/12345 \
  -H "Authorization: Basic <base64 credentials>" \
  -H "Content-Type: application/merge-patch+json" \
  -d '{ "status": "won", "statusSuccessPercentage": 100 }'

Hou er ook rekening mee dat geneste objecten (zoals een adres) vervangen worden, niet diep samengevoegd — een gedeeltelijk genest object versturen overschrijft het volledige object. Stuur altijd de complete geneste structuur mee.

Wat je kan lezen en schrijven

Dezelfde resources die je in de UI beheert, zijn als endpoints beschikbaar, waaronder:

• /api/v2/clients en /api/v2/clients/{id}/contacts
• /api/v2/articles
• /api/v2/posts (herbruikbare, parameter-gestuurde sjablonen voor lijnitems)
• /api/v2/offers en /api/v2/offers/{id}/line-items
• /api/v2/projects

Dat is voldoende oppervlakte voor een AI-agent om een offerte op te stellen, een klant te verrijken, een project te reconciliëren of je pipeline samen te vatten — volledig programmatisch.

⚠️ API-toegang wordt bepaald door gebruikersrollen — lees dit aandachtig

Dit is het deel dat de meeste mensen over het hoofd zien, en het is het belangrijkst zodra je AI naar je account laat schrijven.

Je API key erft de rechten van de Robaws-gebruiker waaraan hij gekoppeld is. Een API key is geen aparte, almachtige master-credential — hij handelt als die gebruiker. Wat die gebruiker mag zien en wijzigen in de interface, is exact wat de API key kan zien en wijzigen. Niets meer.

De praktische gevolgen:

• Lezen versus schrijven is een rol-beslissing, geen API-beslissing. Wil je een AI-assistent die je pipeline kan lezen maar nooit wijzigen, koppel zijn key dan aan een gebruiker met een rol die alleen-lezen-toegang geeft tot de relevante modules. De API geeft dan data terug op GET, maar weigert POST/PATCH/DELETE-pogingen op resources buiten de rechten van die gebruiker.
• Beperk volgens least privilege. Richt geen experimentele AI-agent op een key die aan een administrator-account hangt. Maak een aparte API-gebruiker met een rol die beperkt is tot exact de modules en rechten die de integratie nodig heeft. Als de agent alleen concept-offertes moet maken, mag hij geen klanten kunnen verwijderen of aan facturatie kunnen komen.
• Eén key, één doel. Gebruik aparte API-gebruikers (en dus aparte keys) voor aparte integraties. Zo kan je de toegang van één integratie intrekken of roteren zonder de andere te breken, en toont je audit trail welke gebruiker/agent welke wijziging deed.
• Auditing. Omdat elke key aan een gebruiker is gekoppeld, zijn acties via de API toe te wijzen aan die gebruiker. Gebruik dit om te monitoren wat je AI-integraties effectief doen.

Kortom: de rol die je aan de API-gebruiker toekent is je toegangscontrolebeleid voor AI. Configureer die bewust voordat je een key aan een autonome tool geeft. Geef een agent een schrijf-bevoegde admin-key en hij kan alles wijzigen; geef hem een beperkte alleen-lezen-gebruiker en hij zit veilig binnen de lijnen.

Waar AI in Robaws naartoe gaat

De API is de basis. Daarbovenop lanceren we AI-native mogelijkheden binnen Robaws zelf, geprioriteerd op echte klant-use-cases in plaats van hype. Waarschijnlijke richtingen zijn onder meer hulp bij het opstellen van offertes, samenvattingen van projecten en pipeline, en het bevragen van je data in natuurlijke taal — maar we lanceren elk daarvan pas wanneer het echt nuttig is voor een concreet scenario waar onze klanten mee te maken hebben.

Heb je een specifieke use-case die je graag geautomatiseerd zou zien? Laat het ons weten. Echte scenario's van echte bouwbedrijven zijn precies wat onze roadmap stuurt.

Wil je een partner die dit voor je opzet?

Een robuuste, veilige AI-integratie bouwen — correcte authenticatie, juist afgebakende API-gebruikers, error handling, idempotentie, en de eigenlijke AI-logica daarbovenop — is echt ingenieurswerk. Doe je dit liever niet in-house, werk dan samen met een partner die de Robaws API door en door kent.

Wij raden Libaro aan — zij helpen je Robaws + AI-integratie van begin tot eind ontwerpen en bouwen.

👉 libaro.be

Bijgewerkt op: 05/06/2026