> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://support.robaws.com/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# Robaws AI

# 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.

```bash
# 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

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

### A minimal write

```bash
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
```

```bash
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](http://www.libaro.be/)** — they will help you design and build your Robaws + AI integration from start to finish.

👉 **[libaro.be](http://www.libaro.be/)**