Overview
Webhook tools enable your AI persona to call external HTTP endpoints during conversations. This allows integration with any REST API, enabling your persona to:- Check order or shipment status from your e-commerce system
- Create support tickets in your helpdesk software
- Update CRM records based on conversation context
- Fetch real-time data (weather, stock prices, availability)
- Trigger workflows in external systems
- Send notifications or alerts
- Log conversation events
Creating a Webhook Tool
- Stateful (Database-Saved)
Create the tool
/tools in the Anam Lab:- Click Create Tool
- Select Webhook Tool
- Fill in the configuration:
- Name:
check_order_status(snake_case) - Description: When the LLM should call this webhook
- URL: Your API endpoint
- Method: GET, POST, PUT, PATCH, or DELETE
- Headers: Authentication and content-type headers
- Parameters: JSON Schema for request body
- Await Response: Whether to wait for the response
- Name:
Attach to persona
/build/{personaId}:- Scroll to the Tools section
- Click Add Tool
- Select your webhook tool from the dropdown
- Save the persona
Use in session
Tool Configuration
Required Fields
"server" for webhook tools"webhook" for HTTP endpoint toolscheck_order_status, create_ticket, update_crm_contact- What triggers the webhook call
- What data the webhook provides
- When NOT to use it
"Check order status when customer mentions an order number or asks about delivery, tracking, or shipping. Use the order ID from the conversation."https://api.yourcompany.com/v1/orders/statusGET: Retrieve data - POST: Create
or query data (most common) - PUT: Update entire resource - PATCH: Partial
update - DELETE: Remove resourceOptional Fields
Authorization: API keys or bearer tokensContent-Type: Usuallyapplication/jsonX-API-Key: Alternative auth header- Custom headers specific to your API
true(default): LLM waits for response and uses it in the answerfalse: Fire-and-forget, useful for logging or notifications
How Webhook Tools Work
User mentions relevant information
LLM extracts parameters
check_order_status webhook and extracts parameters:Server makes HTTP request
Your API responds
LLM generates response
Common Use Cases
E-commerce: Order Status
Support: Create Ticket
CRM: Update Contact
Real-time Data: Weather
Availability Check
Best Practices
Security
Use HTTPS endpoints
Use HTTPS endpoints
Secure API credentials
Secure API credentials
Validate webhook responses
Validate webhook responses
Rate limiting
Rate limiting
- Track requests per API key
- Return
429 Too Many Requestswhen limit exceeded - Include
Retry-Afterheader
Performance
Keep responses fast
Keep responses fast
- Target: Under 1 second for best experience
- Maximum recommended: 5 seconds
- Hard timeout: 60 seconds
- Use caching for frequently requested data
- Defer slow operations to background jobs (use split pattern)
- Return partial data quickly rather than waiting for complete results
- Database queries should be indexed and optimized
Use fire-and-forget when appropriate
Use fire-and-forget when appropriate
awaitResponse: false for operations that don’t need to return data:Return only necessary data
Return only necessary data
Error Handling
Return meaningful error messages
Return meaningful error messages
Handle missing parameters gracefully
Handle missing parameters gracefully
Use appropriate HTTP status codes
Use appropriate HTTP status codes
200 OK: Success400 Bad Request: Invalid parameters401 Unauthorized: Invalid API key404 Not Found: Resource doesn’t exist429 Too Many Requests: Rate limit exceeded500 Internal Server Error: Server error
Testing Webhook Tools
Local Development
For local testing, use tunneling services to expose your localhost:Test Mode
Create a test version of your webhook tool:Mock Responses
For development without a backend, use mock API services:Logging and Debugging
Add logging to your webhook endpoint to debug issues:Monitoring Webhook Calls
Webhook tool calls emit lifecycle events on the client that you can use for logging or analytics. UsetoolType and toolSubtype to filter for webhook-specific events:
Troubleshooting
Webhook not being called
Webhook not being called
- Description too vague for LLM to understand when to use it
- System prompt doesn’t mention the webhook capability
- Missing required parameters in conversation
- Make description more specific with trigger words
- Update system prompt to mention the webhook
- Test with explicit parameter values in conversation
- Check server logs to see if request was made
Webhook timing out
Webhook timing out
- Endpoint takes >60 seconds to respond
- Network issues or slow database queries
- Endpoint not accessible from Anam servers
- Optimize endpoint performance
- Check endpoint is publicly accessible (not localhost in production)
- Verify firewall rules allow Anam’s IP range
- Use fire-and-forget (
awaitResponse: false) for slow operations
Authentication errors
Authentication errors
- Incorrect API key or token
- Expired credentials
- Wrong authentication header format
- Verify credentials are current and valid
- Check header format matches API requirements
- Test endpoint directly with same credentials using curl/Postman
- Check for typos in header names (case-sensitive)
Incorrect parameter values
Incorrect parameter values
- LLM extracting wrong values from conversation
- Parameter descriptions unclear
- User providing ambiguous information
- Improve parameter descriptions with examples
- Update system prompt with parameter extraction guidance
- Ask users to confirm values before making webhook call
Advanced Patterns
Chaining Multiple Webhooks
The LLM can call multiple webhooks in sequence: User: “Check my order ORD-12345 and create a ticket if there’s a problem” LLM flow:- Calls
check_order_status→ finds delay - Calls
create_support_ticket→ creates ticket - Responds: “I checked your order and it’s delayed. I’ve created support ticket #789 to investigate.”
Conditional Webhooks
Use system prompt to guide conditional webhook usage:Dynamic Parameters
Extract multiple pieces of information from complex requests:Long-Running Processes (A Recommended Pattern)
For backend processes that take longer than 5 seconds (like generating a report or running a batch job), the conversation can feel stalled. To keep the interaction fluid, we recommend a “split pattern” where you create two separate webhooks. This is a design pattern that you implement on your backend. You are responsible for creating the two endpoints and managing the state of the job. The Anam agent’s role is simply to call the webhooks you provide.Step 1: Create a 'start' webhook
jobId and an estimated completion time.Step 2: Create a 'check status' webhook
jobId. It should return the status and, if complete, the final result (e.g., a download URL).Step 3: Guide the AI with a system prompt
- User: “Can you generate a sales report for last month?”
- AI:
- Calls your
start_report_generationwebhook. - Your backend starts the job, saves its state (e.g.,
status: 'PENDING') in a database, and immediately returns{ "jobId": "job_123", "estimatedTime": "30 seconds" }. - Responds: “I’ve started generating your sales report. It should be ready in about 30 seconds. I can let you know when it’s done.”
- Calls your
- (AI continues the conversation on other topics…)
- AI (after ~30 seconds):
- Proactively calls your
check_report_statuswebhook withjobId: "job_123". - Your backend checks the job’s state. If it’s done, it returns
{ "status": "COMPLETE", "url": "https://.../report.pdf" }. - Responds: “Great news! That sales report you asked for is ready. You can download it here: [link].”
- Proactively calls your

