How to Use HTTP API Actions With ZazzyAgent AI Agents
An AI Agent can understand what a customer wants.
An HTTP API can connect that conversation to another application.
Together, they can turn an AI Agent into an assistant that can actually retrieve information or perform business operations.
Examples:
Check order information
Check inventory
Retrieve a support ticket
Create a lead
Submit a callback request
Check appointment availability
Retrieve shipping information
The HTTP API action
The basic format is:
##call_http_api## : 5
The number represents the configured HTTP API in your ZazzyAgent account.
Use ## in the System Prompt editor to select the configured API.
Three API response modes
The action can be configured with a response behavior.
Reply with the API response
##call_http_api## : 5 | reply_with_response | status, message
The selected response fields can be used as the basis for the customer-facing reply.
Reply with a fixed response
##call_http_api## : 5 | reply_with_static_reply | Thank you! We received your request.
The API runs, and the customer receives the fixed message.
Run silently
##call_http_api## : 5 | no_reply
The API runs without an additional customer-facing response.
Example: Check a support ticket
Customer:
What's happening with my support ticket?
Your AI Agent could be instructed:
When the customer asks about an existing support ticket,
collect the ticket number if it has not already been provided.
Once the ticket number is available,
call the support-status API.
##call_http_api## : 5 | reply_with_response | status, message
Never guess the ticket status.
Example: Create a callback request
Customer:
Can someone call me tomorrow?
The agent collects any required details.
Then:
When the customer confirms the callback request,
call the callback API.
##call_http_api## : 5 | reply_with_static_reply | Thank you! We received your request.
The external system can create the callback request.
Silent API actions
Some API calls don't require a customer-facing message.
For example:
Record customer preference.
When the customer confirms their preferred contact time,
save the information using the configured API.
##call_http_api## : 5 | no_reply
The application performs the update without sending another message.
Live information vs knowledge
This distinction is one of the most important AI design principles.
Knowledge is useful for:
What is your return policy?
An API is useful for:
Has my return request been approved?
The first answer can be static business knowledge.
The second depends on current data.
Never let the AI guess API results
Your System Prompt should explicitly say:
If the API does not return a valid result,
do not guess.
Tell the customer that the information could not be retrieved
and provide the appropriate next step.
This is especially important for:
Prices
Stock
Order status
Payment status
Appointment availability
Delivery status
Use the API only when necessary
Don't call an external API for every customer message.
Example:
Customer:
What are your business hours?
If the answer is already in your knowledge, there's no reason to call an external system.
Customer:
Is there an appointment available tomorrow at 4 PM?
That's a stronger API use case if availability lives in your booking system.
API action + custom field
You can combine an API with saved customer data.
Example:
Customer provides:
Order Number = 12345
Save it:
##save_custom_field## : 42
Then use the relevant information when calling the API.
API action + label
Suppose the customer requests a callback.
You might:
##call_http_api## : 5 | reply_with_static_reply | We've received your callback request.
and:
##add_label## : 12
This creates both an external record and an internal customer classification.
API errors
Your System Prompt should explain what happens if the API fails.
Example:
If the API returns an error or no valid result,
do not invent an answer.
Explain that the information is temporarily unavailable
and offer human support when appropriate.
A complete example
You are the Order Support Agent.
Your responsibility is to help customers get information
about their existing orders.
If the customer asks about an order,
ask for the order number if it is not already known.
When the order number is available,
call the order-status API.
##call_http_api## : 5 | reply_with_response | status, message
Use the API result when responding to the customer.
Never invent order information.
If the API fails or returns no valid result,
tell the customer you could not retrieve the information
and offer human support.
Test the API action
Test at least:
Successful request
API returns valid data.
Expected:
AI explains the result.
Missing information
Customer doesn't provide the required identifier.
Expected:
AI asks for it.
Invalid identifier
Expected:
AI explains that the record could not be found.
API failure
Expected:
AI doesn't guess.
Irrelevant question
Expected:
AI answers from knowledge without unnecessarily calling the API.
The goal isn't merely to make the API call work.
The goal is to make the entire decision → action → result → reply process reliable.