POST
/
tool
curl --request POST \
  --url https://api.clarionhealth.com/v1/tool \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "async": false,
  "type": "function",
  "function": {
    "strict": false,
    "name": "<string>",
    "description": "<string>",
    "parameters": {
      "type": "object",
      "properties": {},
      "required": [
        "<string>"
      ]
    }
  }
}'
{
  "async": false,
  "type": "function",
  "id": "<string>",
  "orgId": "<string>",
  "createdAt": "2023-11-07T05:31:56Z",
  "updatedAt": "2023-11-07T05:31:56Z",
  "function": {
    "strict": false,
    "name": "<string>",
    "description": "<string>",
    "parameters": {
      "type": "object",
      "properties": {},
      "required": [
        "<string>"
      ]
    }
  }
}

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Body

application/json
type
enum<string>
required

The type of tool. "function" for Function tool.

Available options:
function
async
boolean

This determines if the tool is async.

If async, the assistant will move forward without waiting for your server to respond. This is useful if you just want to trigger something on your server.

If sync, the assistant will wait for your server to respond. This is useful if want assistant to respond with the result from your server.

Defaults to synchronous (false).

Example:

false

function
object

This is the function definition of the tool.

For endCall, transferCall, and dtmf tools, this is auto-filled based on tool-specific fields like tool.destinations. But, even in those cases, you can provide a custom function definition for advanced use cases.

An example of an advanced use case is if you want to customize the message that's spoken for endCall tool. You can specify a function where it returns an argument "reason". Then, in messages array, you can have many "request-complete" messages. One of these messages will be triggered if the messages[].conditions matches the "reason" argument.

Response

201 - application/json
type
enum<string>
required

The type of tool. "function" for Function tool.

Available options:
function
id
string
required

This is the unique identifier for the tool.

orgId
string
required

This is the unique identifier for the organization that this tool belongs to.

createdAt
string
required

This is the ISO 8601 date-time string of when the tool was created.

updatedAt
string
required

This is the ISO 8601 date-time string of when the tool was last updated.

async
boolean

This determines if the tool is async.

If async, the assistant will move forward without waiting for your server to respond. This is useful if you just want to trigger something on your server.

If sync, the assistant will wait for your server to respond. This is useful if want assistant to respond with the result from your server.

Defaults to synchronous (false).

Example:

false

function
object

This is the function definition of the tool.

For endCall, transferCall, and dtmf tools, this is auto-filled based on tool-specific fields like tool.destinations. But, even in those cases, you can provide a custom function definition for advanced use cases.

An example of an advanced use case is if you want to customize the message that's spoken for endCall tool. You can specify a function where it returns an argument "reason". Then, in messages array, you can have many "request-complete" messages. One of these messages will be triggered if the messages[].conditions matches the "reason" argument.