Robaws & AI

Our vision

At Robaws we believe your ERP should not be a walled garden. Your quotations, projects, items, customers and planning are your data — and the most valuable thing you can do with data in 2026 is to let software, and increasingly AI, work with it on your behalf.

That is why everything you see in the Robaws interface is also available through our public REST API (v2). AI assistants, agents and automation tools can already read from and write to your account today, securely and entirely under your control. We are not waiting for a magical "AI button" — the foundation is in place, and you can start building on it right now.

Over time we will also release AI-native functions inside Robaws itself (drafting quotations, summarising projects, flagging risks, answering questions about your pipeline). We are deliberately rolling these out per use-case scenario rather than as a gimmick, so that every function earns its place. Until then — and alongside those functions — the API is the door to everything.

⚠️ Please note: This guide is written for developers. If terms such as HTTP Basic auth, base64-encoded credentials, idempotent PATCH requests and merge-patch content types mean nothing to you, this is the moment to bring in help. Skip to the end — we will point you to a partner who does this every day.

How AI connects to Robaws

The Robaws API is a standard RESTful HTTPS interface. Any AI tool, agent framework or middleware that can send authenticated HTTP requests and process JSON can integrate with it. There is no proprietary SDK to install — if it speaks HTTP, it speaks Robaws.

Base host (always):

https://app.robaws.com

All endpoints sit under /api/v2/. The full machine-readable OpenAPI specification is published here:

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

Point your LLM tooling, code generator or agent framework at that spec and it can describe every available resource, method and payload schema by itself.

Authentication

The API uses HTTP Basic authentication over TLS. You authenticate with an API key and an API secret, joined as key:secret and base64-encoded in an Authorization header.

# The 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"

A 200 OK confirms that your credentials are valid. A 401 Unauthorized means the key/secret pair is wrong or has been revoked. Treat the secret like a password: never put it in client-side code, browser apps or anything an end user can inspect. Store it in a server-side secret manager or environment variable, and rotate it if you suspect it has leaked.

A minimal read

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

A minimal 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"
      }'

Updating records (this is where many go wrong)

Partial updates use PATCH and require a specific content type. A plain application/json body is rejected with 415 Unsupported Media Type. Use:

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 }'

Also bear in mind that nested objects (such as an address) are replaced, not deeply merged — sending a partial nested object overwrites the entire object. Always send the complete nested structure.

What you can read and write

The same resources you manage in the UI are available as endpoints, including:

• /api/v2/clients and /api/v2/clients/{id}/contacts
• /api/v2/articles
• /api/v2/posts (reusable, parameter-driven templates for line items)
• /api/v2/offers and /api/v2/offers/{id}/line-items
• /api/v2/projects

That is enough surface for an AI agent to draft a quotation, enrich a customer, reconcile a project or summarise your pipeline — entirely programmatically.

⚠️ API access is governed by user roles — read this carefully

This is the part most people overlook, and it matters most as soon as you let AI write to your account.

Your API key inherits the permissions of the Robaws user it is linked to. An API key is not a separate, all-powerful master credential — it acts as that user. What that user is allowed to see and change in the interface is exactly what the API key can see and change. Nothing more.

The practical consequences:

• Read versus write is a role decision, not an API decision. If you want an AI assistant that can read your pipeline but never change it, link its key to a user with a role that grants read-only access to the relevant modules. The API then returns data on GET, but refuses POST/PATCH/DELETE attempts on resources outside that user's permissions.
• Restrict along least-privilege lines. Do not point an experimental AI agent at a key attached to an administrator account. Create a separate API user with a role limited to exactly the modules and permissions the integration needs. If the agent only has to create draft quotations, it should not be able to delete customers or touch invoicing.
• One key, one purpose. Use separate API users (and therefore separate keys) for separate integrations. That way you can revoke or rotate one integration's access without breaking the others, and your audit trail shows which user/agent made which change.
• Auditing. Because every key is linked to a user, actions performed through the API can be attributed to that user. Use this to monitor what your AI integrations are actually doing.

In short: the role you assign to the API user is your access control policy for AI. Configure it deliberately before you hand a key to an autonomous tool. Give an agent a write-enabled admin key and it can change anything; give it a restricted read-only user and it stays safely within the lines.

Where AI in Robaws is heading

The API is the foundation. On top of it we are releasing AI-native capabilities inside Robaws itself, prioritised on real customer use cases rather than hype. Likely directions include help with drafting quotations, summaries of projects and pipeline, and querying your data in natural language — but we will only release each of these once it is genuinely useful for a concrete scenario our customers are dealing with.

Do you have a specific use case you would like to see automated? Let us know. Real scenarios from real construction companies are exactly what drives our roadmap.

Would you like a partner to set this up for you?

Building a robust, secure AI integration — correct authentication, properly scoped API users, error handling, idempotency, and the actual AI logic on top — is genuine engineering work. If you would rather not do this in-house, work with a partner who knows the Robaws API inside out.

We recommend Libaro — they will help you design and build your Robaws + AI integration from start to finish.

👉 libaro.be

Updated on: 09/09/2026