Skip to content
Try Free →

The custom_webhook skill

Last updated: · 5 min read

What the skill does

AskVault's built-in skills cover the common patterns: lead capture, escalation, scheduling, order status and sentiment alerts. custom_webhook is the escape hatch for everything else.

When the AI decides your action fits the conversation, it fills in the parameters you defined and calls your endpoint. Your endpoint does whatever it wants: write to a database, trigger a workflow, call an API we don't have a native integration for, fire a Slack message with custom formatting.

The skill is on Business and above. Business+

Real use cases

Five good fits:

  • A CRM AskVault does not connect to. Pipedrive, Close, Copper, Insightly. Your endpoint calls your CRM's API.
  • Custom internal systems. Your home-grown ticketing, inventory, or returns systems. Webhook bridges to your backend.
  • Real-time order status from a non-Shopify, non-WooCommerce store. Magento, BigCommerce, custom Rails store. Webhook calls your store's API.
  • Slack notifications with custom formatting. Beyond AskVault's built-in Slack alerts. Webhook fires to Slack's webhook with your specific message template.
  • Trigger a Zapier or Make workflow. Webhook is the universal hand-off to any "no-code" automation product.

Setup

Configure under Automation > Skills > custom_webhook:

  1. Enable the skill.
  2. Webhook URL. Where AskVault POSTs when the skill fires. Every call is currently sent as a POST with a JSON body, even if you choose another Method for the action. Support for the method you choose is rolling out behind a flag and is not switched on yet. Once it is on, GET and DELETE send the parameters as a query string (?order_id=1042) with no body, after any query string already in your URL; POST, PUT and PATCH send them as the JSON body; and a GET always calls your endpoint instead of reusing a recent result.
  3. Authentication. A single custom header: use it as a Bearer token (name it Authorization) or as an API key under whatever header name your endpoint expects. The value is stored encrypted.
  4. Request schema. Define the fields that go in the POST body: see below.

There are no trigger phrases: the AI decides when to call the action from its description and the conversation. Test it in the chat playground with a message that should need it, and turn on dry run while you test if your endpoint changes data.

Request payload

You define a JSON Schema for the parameters this action needs: field names, types, which are required: under Automation > Skills > custom_webhook. When the skill fires, the bot fills in those parameters from the conversation, and AskVault POSTs exactly that object as the JSON body to your webhook URL. For example, a schema with ticket_subject, priority, and customer_email fields produces a request body like:

{
"ticket_subject": "Can't log in to my account",
"priority": "high",
"customer_email": "[email protected]"
}

The shape is entirely up to your schema: there's no fixed envelope of conversation/customer metadata added around it.

Response handling

Return HTTP 200 with a JSON body describing what happened. AskVault passes that body back to the LLM as context, and the bot synthesizes it into a natural-language reply: there's no required reply field it extracts verbatim, so keep the response reasonably self-explanatory (status, any ID the customer would want, a short message). A status code >= 400 makes the bot say something generic like "I tried to do that but something failed; let me get a human."

Security

The custom_webhook skill authenticates itself with the custom header you configured above: it does not sign requests with HMAC. If your endpoint needs to reject anything that isn't a real AskVault call, require and check that header server-side:

function verifyAskVaultRequest(req, expectedHeaderName, expectedValue) {
return req.headers[expectedHeaderName.toLowerCase()] === expectedValue;
}

Anyone who guesses your webhook URL but doesn't know the header value can't get past this check. Rotate the header value from Skills > custom_webhook if you suspect it's leaked.

(AskVault's separate outbound event webhooks: for events like conversation.resolved and lead.captured: do HMAC-sign every delivery with X-AskVault-Signature; that's a different feature from this skill.)

Policy bounds

The skill respects a rate limit: up to 60 invocations per workspace per hour. This is a fixed platform default, not a per-workspace tunable setting. Hitting it surfaces a polite fallback to the customer.

Latency

The visitor waits while your endpoint runs, so its response time adds straight to the reply time. Aim to answer in a second or two. The skill gives up after 15 seconds.

For very slow operations (10+ seconds), use a fire-and-forget pattern: your endpoint replies at once that the work has started, finishes it in the background, and tells the customer the outcome another way, such as by email.

Limits

  • Plan availability. Business and above.
  • Coming plan change (not switched on yet). When the new Starter plan limits are switched on, custom actions become available from Starter, with a per-agent limit of 5 on Starter, 10 on Growth, 20 on Business and 50 on Enterprise. An agent that already has more actions than its plan allows keeps all of them; it just can't add another until it is under the limit. Each step of an action conversation uses credits: an answer that calls actions is charged once for every AI step it takes, not once per answer.
  • Response timeout. 15 seconds. Beyond that, AskVault assumes failure.

Common pitfalls

Webhook never fires. The AI does not see a reason to call it. Make the action's name and description say plainly when it should be used, and check the skill is on.

Auth header check fails. Header value mismatch between AskVault and your endpoint. Re-copy the value from the dashboard and update your endpoint.

Reply reads oddly. The bot synthesizes its reply from whatever JSON your endpoint returns: keep the response body self-explanatory (status, any ID the customer would want, a short message) so the LLM has something clear to phrase.

Bot says generic error. Your endpoint returned an error status or timed out. Check your endpoint's logs.

FAQ

Does the visitor have to confirm before an action runs?

For the single-endpoint setup, the bot is built to show a confirmation card and call your endpoint only after the visitor agrees; today it is the bot that judges the card was answered. Actions you add one by one in the Actions builder do not pause for confirmation yet. A fix is rolling out behind a flag and is not switched on yet. Once it is on, every action pauses for confirmation unless you set its method to GET, and an action follows the teammate-approval setting of custom_webhook. AskVault then runs the action only after the visitor answers that card with a yes (the card's button, or a typed "yes" on WhatsApp, Telegram or SMS) within 10 minutes, and each yes runs it once. The bot cannot skip this step. Set GET only on actions that just look something up: a GET action runs without asking. Your endpoint should still check that each request makes sense.

Can the bot call multiple webhooks per conversation?

Yes, one after another. You can add several actions (up to 10 per workspace), each with its own URL and schema, and the AI calls whichever fits.

Can I return JSON other than the standard schema?

Yes: there is no standard response schema to match. Return whatever JSON shape makes sense for your endpoint; it's passed to the LLM as context and the bot phrases a reply from it.

Is there an idempotency mechanism?

Yes, on AskVault's side: a successful call is remembered for one hour, and an identical repeat inside that window is answered from that memory instead of hitting your endpoint again, so you don't need to build your own dedup for that case. Today "identical" means the same parameters anywhere in your workspace, so two different actions, or two different visitors, sending the same parameters within the hour can see the second call skipped. A fix that only treats a call as a repeat when it is the same action, with the same parameters, in the same conversation is rolling out behind a flag and is not switched on yet. AskVault doesn't retry on success; on 5xx failures it retries up to 2 more times (configurable per action).

Can the skill fire on every message?

No. The AI calls an action only when the conversation calls for it. To send every message somewhere, use the message.created webhook instead.

Was this page helpful?