Dolphy Docs
AI and RAG

Connect the agent to workflows

Actions let the agent send a structured request to an external system during a conversation. Suitable examples include reading availability, checking an order status or creating an appointment request after user confirmation.

Dolphy action setup with clean sample data

Read and write operations

A read tool does not change state; for example, it lists available times. A write tool creates or changes a record. Write operations should request confirmation with a summary the customer can understand. User confirmation does not replace authorisation and validation in the receiving system.

Webhook contract

Each tool defines a name, description, HTTPS endpoint, fields and the response fields exposed to the model. Requests are always POST with a JSON body. A schema guides the model to produce expected parameters instead of arbitrary text. Dolphy bounds the request body by declared types and size, then reduces the response to a safe result shape.

Every request is signed with HMAC-SHA256 using a shared secret (Standard Webhooks: webhook-id, webhook-timestamp and webhook-signature headers). The receiving system should validate the signature against the raw body, apply a reasonable timestamp tolerance and reject replayed old requests.

Network safety

A webhook target is not accepted based on URL syntax alone. Local, loopback, link-local and private IP targets are blocked; resolved DNS addresses are checked again and redirects are not followed. The endpoint must sit on one of the allowed domains from Setup. This is designed to prevent the agent tool from becoming a server-side request forgery path.

Failure behaviour

A timeout, invalid response or remote error is not presented as a successful operation. The agent gives a short explanation and offers a safe retry or human support. Write endpoints should accept an idempotency key when possible so a network retry cannot create the same record twice.

On this page