SWAIG function signature request
Sent once per SWAIG.includes entry when an AI
agent loads, to discover the functions your server hosts. Every way of building an agent sends it —
SWML you write yourself, SWML a Server SDK generates, or an agent you configure in your Dashboard —
because they all resolve includes the same way.
Reply with the function definitions you host, each shaped like an entry in
SWAIG.functions — function,
description, and parameters. Three forms are accepted:
- an array of definitions, the usual one;
- a single definition on its own;
- an object
{functions, defaults}, wheredefaultssets SWAIG defaults across the definitions it carries — useful when they share aweb_hook_urlor auth.
Every definition you return is registered, whether or not it was named in the request’s
functions list.
This is not the payload a function call sends. It goes to the includes entry’s url, using
auth_user and auth_password when set. Your endpoint can also receive it outside of a call, as a
check that it answers, so answer it the same way. When your project has a signing key, the request
carries an X-SignalWire-Signature header you can verify.
Payload
What the request is asking of you. Always get_signature.
The function names the includes entry asked for. This list can be empty, and it does not limit
your reply: every definition you return is registered, whether or not it is named here.
The content type of the request body. Always text/swaig.
How the body is delivered. Always function signature request.
The meta_data you set on the includes entry. Omitted when you set none.
The token scoping meta_data. Present on the check your endpoint can receive outside of a call,
where it is a fixed value with nothing to interpret, and absent during a call.