Connect your own system's API

If your booking system or CRM has an API, your receptionist can use it on calls and in your website's chat. Each request it can make is its own tool, written as a cURL you can read before anything is sent. Here's how, with a full example.

How it works

In Tools, press New tool and pick Your system's API. Each tool is one request, like seeing free times or booking a class: add one for each.
Paste that request's part of your API's documentation, a cURL example from it, or describe it in words, and press Make the cURL.
Digui writes the request as a cURL, with {{placeholders}} for what changes on each call. Next to it you see the request Digui understood: what it sends, where, and who fills each value.
Type your API key (or a username and password), or use the one you saved in another API connector for the same address. It's kept encrypted and never shown again.
Press Test, then Save, and give it to your receptionists.

An example: booking a class at Sunrise Yoga

Sunrise Yoga is a made-up studio. Its API's documentation for booking a class says:

POST https://api.sunriseyoga.example/v1/bookings
Books a class for a member.
Headers: Authorization: Bearer <your API key>, Api-Version: 2
Body (JSON):
  class_id    integer   The class
  start       string    When, as YYYY-MM-DDTHH:MM
  member_id   integer   The member, or
  phone       string    the member's phone number
  notes       string    Optional

The cURL Digui makes

From that, Digui writes this cURL. You can edit it: what you see is what's sent. {{key}} is where your key goes, so the cURL never holds it. Api-Version: 2 is a fixed value, sent as written on every call.

curl -X POST 'https://api.sunriseyoga.example/v1/bookings' \
  -H 'Authorization: Bearer {{key}}' \
  -H 'Api-Version: 2' \
  -H 'Content-Type: application/json' \
  --data-raw '{"class_id": {{class_id}}, "start": "{{start}}", "member_id": {{member_id}}, "phone": "{{phone}}", "notes": "{{notes}}"}'

Who fills each value

Who the person is never comes from what they say. On a call, it's the number the call comes from. In your website's chat, it's the member id your website signs. If neither is there, the receptionist says it can't do that here. In JSON, text goes in quotes ("{{start}}"), and numbers and yes/no go without ({{class_id}}).

Value	Who fills it	Type	Optional	What it is
{{class_id}}	The receptionist asks the person	Whole number	No	The class
{{start}}	The receptionist asks the person	Text	No	When, as YYYY-MM-DDTHH:MM
{{member_id}}	A signed value from your website's chat	Whole number	No	The member
{{phone}}	The caller's phone number	Text	No	The number the call comes from
{{notes}}	The receptionist asks the person	Text	Yes	Anything the person wants the studio to know

Test, then save

Test sends a read for real, with sample values you type. A booking changes something, so Test first shows the request it would send, with your key as ********, and sends it only when you press Send it for real. Save connects it: your receptionists get a tool that sends exactly that request, and they ask the person before it books.

What Digui sends, and what it won't

Only to the address in the cURL, over https, and only if it's a public address. A value from a call never changes where a request goes.
A key, a username and password, or nothing. Never a sign-in with Google or another account: for those, use the app's own tool.
JSON or form bodies. No files, cookies, proxies or -k.
It waits 10 seconds at most, never follows redirects, and passes on the first 20 KB of an answer.
Your saved key never reaches the AI, the logs or the dashboard: wherever it could show, it's ********. Paste the documentation with a stand-in like YOUR_API_KEY, not your real key (if you paste one anyway, Digui moves it out of the cURL and saves it hidden).

Last updated: November 5, 2026