A message doesn't send.

An API call fails.

A JSON response causes an error.

A flow stops at a particular step.

Instead of guessing which part is broken, check the Bot Error Logs.

The current platform provides an error-log area that records flow-related errors and provides information such as the error message and time, with an option to jump back to the affected flow.

What are Bot Error Logs?

Bot Error Logs show errors generated during automation execution.

They help answer:

What went wrong?

and:

When did it happen?

They can be especially useful for technical flow problems involving APIs, JSON, URLs and other configured components.

Why should you check the logs?

A customer saying:

The bot isn't working.

doesn't tell you where the problem is.

The error log may show something specific such as:

JSON Decode Error

or:

403

That immediately gives you a direction for troubleshooting.

Open Bot Error Logs

Open the relevant Bot Manager area.

Find the options menu.

Open:

Bot Error Logs

The exact placement may vary with the current dashboard, but the error log is available from the bot-management options.

What information can you see?

The current error log provides information such as:

• Error number

• Error message

• Error time

• Action/edit option

The error message is the most important part when diagnosing a problem.

Use the timestamp

The time of the error helps you match the log entry to a specific customer interaction.

For example:

Customer reported a problem at 3:05 PM.

Find the error around:

3:05 PM.

This can identify the failed flow execution.

Open the affected flow

Where the error entry provides an edit/jump option, use it to return to the flow that generated the error.

The current error-log interface provides a way to jump directly to the relevant flow from an error entry.

Common error: JSON Decode Error

This usually means ZazzyAgent received data that wasn't valid JSON or wasn't in the expected format.

A common place to investigate is:

• HTTP API

• JSON-based integration

• External data

• Dynamic-list data

Check the actual response/request structure.

Common error: 403

A 403 error generally indicates that access was denied.

Possible causes include:

• Authentication

• Permission

• Expired credential

• Restricted URL

Check the external system and credentials.

Common error: 404

A 404 usually means the requested URL/resource wasn't found.

Check:

• API URL

• Webhook URL

• Resource ID

• Endpoint path

A small URL mistake can cause this.

Error logs and API troubleshooting

If an API flow isn't working:

Don't immediately rebuild the flow.

First check:

Bot Error Logs
       ↓
Exact error
       ↓
Affected flow
       ↓
API configuration

This gives you evidence instead of guessing.

Error logs and custom variables

When a flow depends on dynamic customer data, also inspect the values being used.

For example:

order_id
customer_id
membership_status

If one of these values is missing or incorrect, the subsequent API call may fail.

The current debugging tools also expose per-user custom variables that can help when diagnosing dynamic data.

Error logs vs customer support

If a customer reports:

The bot didn't reply.

the error log tells you whether the platform recorded an execution error.

If there is no relevant error, investigate other causes such as:

• Trigger wasn't matched

• Flow wasn't active

• Message wasn't received

• Channel-level issue

• Routing issue

Don't assume that every missing reply creates an error-log entry.

Don't clear logs immediately

The error log is useful evidence.

Don't clear it before investigating active problems.

The current platform provides a Clear Log action, but clearing removes the visible error history.

Investigate first.

Use a fresh test after fixing

After changing the flow:

1. Save the flow.

2. Trigger it again.

3. Check whether the problem occurs.

4. Check the error log again.

You want to know whether the same error reappeared.

Example: Broken API URL

Customer:

Check my order.

Flow:

User Input

→ Order Number

→ HTTP API

→ Error.

Open logs.

You see:

404

Check the API endpoint.

You discover the configured URL has the wrong path.

Fix it.

Run the test again.

Example: Invalid JSON

Your API returns something unexpected.

The log shows:

JSON Decode Error.

Check the external response.

You discover the response isn't valid JSON.

Fix the external API response or the parsing/mapping configuration.

Example: Missing authentication

The external server returns:

403

Check the authentication configuration.

Confirm the credential and permissions.

Then test again.

Use logs alongside normal testing

Don't rely only on the error log.

Use both:

Customer test

Flow inspection

Error logs

This gives you a much clearer picture.

A practical troubleshooting process

When a flow fails:

Step 1

Reproduce the problem.

Step 2

Record the approximate time.

Step 3

Open Bot Error Logs.

Step 4

Find the matching error.

Step 5

Read the exact error message.

Step 6

Open the affected flow.

Step 7

Fix the relevant component.

Step 8

Run the test again.

Step 9

Confirm the error no longer appears.

Keep the problem specific

Instead of saying:

The bot is broken.

Try to identify:

The HTTP API call returns 403.

or:

The flow produces a JSON Decode Error.

Specific errors usually lead to specific fixes.

The core idea

Bot Error Logs are the platform's evidence trail for flow execution problems.

When an automation behaves unexpectedly:

Check the evidence before changing the automation.

That one habit can save a lot of unnecessary rebuilding.

That means your flow doesn't always have to contain the information itself.

For example:

Customer asks for a service.

Your flow can look up the service information from a Google Sheet and then use that information in the conversation.

This is particularly useful when your team needs to update the underlying information without constantly editing the chatbot.

The current platform supports Google Sheet Data Fetch inside Flow Builder and can use retrieved values in subsequent chatbot replies.

When does this make sense?

A Sheet is useful when:

• Information changes regularly.

• Non-technical staff need to maintain it.

• The data is relatively simple.

• You don't need a full database.

• The flow needs to retrieve a value during a conversation.

Example

Your Sheet contains:

A customer chooses:

Ahmedabad

The flow can retrieve Rahul's information and use it in the response.

Prepare your Sheet

Create clear headers.

For example:

City
Contact Person
Phone

Avoid unclear headers such as:

Column1
Column2
Column3

Clean headers make mapping easier.

Connect your Sheet

Connect your Google account in the Google Sheets integration.

Then add the existing Sheet or create a new one.

For the complete connection process, see How to Connect Google Sheets to ZazzyAgent.

Create custom fields

Decide what data you want to retrieve.

For the example above:

Contact Person

Phone

Create custom fields if needed.

Create the Data Fetch configuration

Open the Google Sheet Data Fetch settings.

Create a campaign.

Choose the relevant Sheet.

Configure the search and response mapping.

Build the Flow

Open Flow Builder.

Create the customer journey that should use the Sheet information.

For example:

Customer
   ↓
Choose City
   ↓
Google Sheet Data Fetch
   ↓
Contact Information
   ↓
Reply

Use interactive choices

You can use buttons or another suitable interactive element to let the customer choose what they want.

Example:

Which city are you looking for?

Ahmedabad

Mumbai

Delhi

The selected value can be used as the lookup value.

Connect the Data Fetch component

Place the Google Sheet Data Fetch component at the point where you need the external information.

Configure it to use the Data Fetch campaign you created.

The current Flow Builder documentation identifies Google Sheet Data Fetch as one of the available Flow Builder elements.

Use the returned data

Suppose the matching Sheet row is:

Ahmedabad | Rahul | +919...

The corresponding custom fields can then be used in your next message.

Example:

Our Ahmedabad contact is Rahul.

You can reach him at +91...

Create a fallback

Never assume there will always be a matching row.

Build a no-result response.

For example:

I couldn't find information for that location. Please choose another city.

Use Sheet data in conditions

The retrieved value can be used as part of your automation where your configured fields support conditions.

For example:

City = Ahmedabad
       ↓
Ahmedabad Flow

City = Mumbai
       ↓
Mumbai Flow

Use it with AI

AI can help determine what the customer wants before the Sheet lookup.

Example:

Customer:

I need someone in Ahmedabad.

The AI can understand:

City = Ahmedabad

Then your automation can retrieve the relevant Sheet data.

This combines natural-language understanding with structured business data.

Use it with User Input

Another approach is to collect the information first.

User Input
   ↓
City
   ↓
Google Sheet Data Fetch
   ↓
Return matching record

Use it with APIs

Google Sheet data can also become an intermediate step before another action.

For example:

Customer
   ↓
Sheet Lookup
   ↓
Provider Phone
   ↓
HTTP API

This can be useful when the Sheet contains information required by an external system.

Example: Service marketplace

Your Sheet contains:

Customer:

I need an electrician in Ahmedabad.

Your automation can identify the relevant service and location, retrieve the matching record and present it.

Example: Branch information

Sheet:

Customer selects:

Mumbai

The flow returns the Mumbai branch information.

Example: Staff directory

Sheet:

A flow can retrieve the correct contact information based on the customer's selected department.

Keep the Sheet as the source of truth

If the information changes frequently, don't duplicate the same information in multiple flow messages.

For example, if a branch phone number changes:

Bad approach:

Update ten chatbot messages.

Better:

Update the Google Sheet.

Then the lookup uses the latest data.

Data Fetch isn't a spreadsheet database

Google Sheets is convenient, but it isn't automatically the right tool for every business.

Use it for relatively simple lookup data.

For complex, transactional systems, use an API or proper backend.

Test the full flow

Test:

• Valid lookup

• No match

• Multiple matches

• Incorrect input

• Empty data

• Updated spreadsheet value

Common mistakes

Sheet is connected but flow doesn't return data

Connection and Data Fetch configuration are separate steps.

Correct Sheet, wrong campaign

Check that the Flow uses the intended Data Fetch campaign.

Correct row, empty response

Check custom-field mapping.

Button value doesn't match Sheet value

Check the exact search term.

A simple mental model

Google Sheet
    ↓
Data Fetch
    ↓
Find Row
    ↓
Save Result
    ↓
Flow Builder
    ↓
Use Result

This turns Google Sheets into a simple operational data source for your conversations.

ZazzyAgent can also look up information from a Google Sheet during a conversation and use the result in the next step.

This is useful when your information changes regularly but doesn't need a full database or custom API.

For example:

Customer asks for a plumber.

Your ZazzyAgent flow can search your Google Sheet and return the relevant plumber's information.

The current Google Sheet Data Fetch feature supports retrieving spreadsheet data for use in chatbot replies across supported channels.

What is Google Sheet Data Fetch?

It lets a ZazzyAgent flow search connected spreadsheet data and use the matching information during the conversation.

The basic architecture is:

Customer
   ↓
Input / Selection
   ↓
Google Sheet Data Fetch
   ↓
Matching Row
   ↓
Custom Fields
   ↓
Reply

When should you use it?

Use Google Sheet Data Fetch when the information changes regularly and is easier for your team to maintain in a spreadsheet.

Examples:

• Service providers

• Locations

• Contact lists

• Staff directories

• Available services

• Simple price tables

• Branch information

• Product information

Example: Service directory

Imagine your Sheet contains:

A customer says:

Plumber

ZazzyAgent can search the Sheet for the matching service and retrieve:

Rahul

and:

+91...

Before you start

You need:

• Connected Google account

• Google Sheet

• Clean column headings

• Data you want to search

• Appropriate custom fields for the values you want to use

Prepare your Google Sheet

Keep the data structured.

Example:

Avoid putting several unrelated values into one cell.

Connect Google Sheets

Connect your Google account through the Google Sheets integration.

Then add the existing Sheet or create a new one.

This step is different from actually configuring Data Fetch.

Your Sheet must already be available to ZazzyAgent.

Create custom fields

Suppose you want to retrieve:

Name

Phone

Create appropriate custom fields if they don't already exist.

For example:

Provider Name

Provider Phone

The Data Fetch result can then be saved into those fields.

Create a Data Fetch campaign

Open the Google Sheet Data Fetch configuration.

Create a new campaign.

Give it a useful name.

For example:

Service Provider Lookup

Avoid:

Sheet Test

Select the Google Sheet

Choose the Sheet containing the information you want to search.

Make sure it's the correct Sheet.

Businesses often have several spreadsheets.

Configure the search

Define what information the workflow should use to find the appropriate row.

For example:

Customer's selection
        ↓
Search Service column
        ↓
Matching row

The current Data Fetch workflow can search spreadsheet information based on the value received from the conversation and then make selected row data available through custom fields.

Map the returned columns

Suppose the matching row contains:

Service
Name
Phone

Map:

Name
 ↓
Provider Name

Phone
 ↓
Provider Phone

Now your flow can use the returned information.

Use the data in a reply

Your next message might say:

We found a plumber for you.

Rahul

+91...

The exact variable syntax depends on how the corresponding custom fields are exposed in your message configuration.

Use it with buttons

A particularly clean pattern is:

What service do you need?

Plumber

Electrician

Cleaner

The button selection becomes the search value.

The current Google Sheet Data Fetch workflow supports using interactive selections to search the configured Sheet and retrieve matching row data.

Example flow

Choose Service
      ↓
[Plumber]
[Electrician]
[Cleaner]
      ↓
Google Sheet Data Fetch
      ↓
Find matching row
      ↓
Save returned data
      ↓
Reply

Keep the search column consistent

Suppose your Sheet contains:

Plumber
Electrician
Cleaner

Your button text should correspond to those values if the workflow is designed to search using the button text.

If your Sheet says:

Electrical Services

while the button says:

Electrician

the lookup may not find the expected row unless your matching configuration accounts for the difference.

What if there are duplicate matches?

Suppose your Sheet contains:

You need to decide how your workflow should handle multiple matches.

Don't assume a spreadsheet lookup is automatically the same as a database query.

Structure your data around the result you actually want.

Keep Sheets clean

Avoid:

• Blank header rows

• Random columns

• Inconsistent spellings

• Duplicate entries

• Mixed data types

The cleaner the Sheet, the easier the automation is to maintain.

Update the Sheet without rebuilding the flow

One advantage of this setup is that your team can update the source data in Google Sheets.

For example:

Rahul changes his phone number.

Update the spreadsheet.

The lookup can use the updated information without you rewriting the entire chatbot flow.

This is one reason Data Fetch is useful for operational information that changes regularly.

Data Fetch vs sending data to Google Sheets

These are opposite directions.

Data Fetch

Google Sheet → ZazzyAgent.

User Input to Sheet

ZazzyAgent → Google Sheet.

Don't confuse the two.

Data Fetch vs HTTP API

Use:

Google Sheet Data Fetch

when your source is a spreadsheet.

Use:

HTTP API

when your source is an external application/API.

Example: Branch locator

Sheet:

Customer:

Ahmedabad

The flow searches the Sheet and returns the relevant branch information.

Example: Service provider

Customer:

Electrician

The flow finds the matching provider and returns the information.

Example: Internal directory

Customer:

Sales

The Sheet contains your sales contact.

The automation can retrieve and present it.

What if no match is found?

Plan for it.

For example:

I couldn't find a matching service. Please choose another option or contact our team.

A lookup should have a fallback path.

Test these cases

Test:

Valid match

No match

Different capitalization

Extra spaces

Duplicate values

Empty result

Common problems

Nothing is returned

Check the search value and Sheet data.

Wrong row is returned

Check for duplicate matches.

Returned fields are empty

Check the mapping from Sheet columns to custom fields.

Data is outdated

Update the Sheet.

Flow works manually but not from the button

Check the button text against the Sheet search value.

The architecture

Google Sheet
     ↓
Data Fetch Campaign
     ↓
Search
     ↓
Matching Row
     ↓
Custom Fields
     ↓
ZazzyAgent Reply

Google Sheet Data Fetch is essentially a simple way to turn a spreadsheet into a live lookup table inside your chatbot conversations.

An external system may send ZazzyAgent information such as:

{
  "name": "Rahul",
  "phone": "+919XXXXXXXXX",
  "email": "rahul@example.com",
  "lead_type": "Enterprise"
}

ZazzyAgent needs to know what each value means and where it should be stored or used.

That's what field mapping is for.

What is webhook field mapping?

Field mapping connects a value received from an external webhook to a field that ZazzyAgent can use.

For example:

Webhook:
customer_name
       ↓
ZazzyAgent:
Name

Another:

Webhook:
lead_type
       ↓
Custom Field:
Lead Type

Why does mapping matter?

Without correct mapping, the webhook can arrive successfully while your automation still doesn't work.

You may see:

Webhook received.

but later discover:

Customer name is empty.

or:

The phone number wasn't found.

The request arrived.

The problem is what happened after it arrived.

Example webhook payload

Suppose your website sends:

{
  "full_name": "Rahul Sharma",
  "customer_phone": "+919876543210",
  "service": "Consultation",
  "budget": "50000"
}

You could map:

The exact available system fields and custom fields depend on your configuration.

Step 1: Send a test webhook

Before mapping anything, send a real sample request from the external system.

The sample should contain realistic values.

For example:

Name: Rahul Sharma
Phone: +919876543210
Service: Consultation
Budget: 50000

This makes it easier to identify each incoming field.

Step 2: Inspect the received payload

Look at the webhook data ZazzyAgent captured.

You may see fields such as:

full_name
customer_phone
service
budget

Pay attention to the exact names.

Don't assume:

phone

and:

customer_phone

are the same thing.

They are different field names unless you map them accordingly.

Step 3: Decide where each value belongs

For each incoming value, ask:

Is this a standard customer property?

or:

Is this business-specific information?

For example:

Standard information

Name

Phone

Email

Business-specific information

Budget

Service Interest

Company Size

Preferred Date

Use custom fields for information specific to your business.

Step 4: Create custom fields where needed

Suppose your webhook sends:

budget

and you don't already have a Budget field.

Create an appropriate custom field.

For example:

Budget

Then map the incoming budget value to it.

See ZazzyAgent Custom Fields Guide.

Step 5: Map the phone number carefully

Phone mapping is especially important when the webhook will trigger a WhatsApp message.

Your workflow needs to know which customer the phone number belongs to.

Make sure the external system sends the number in the expected international format.

For example:

+919876543210

rather than an ambiguous local format.

Step 6: Map the name

If the incoming field is:

full_name

and your destination is the customer's name field, connect those values appropriately.

Then your automation can personalize messages where supported.

Step 7: Map custom information

Suppose the webhook contains:

service = Consultation

Create or select:

Service Interest

Then map:

service
   ↓
Service Interest

Step 8: Use mapped data in the next step

Once the information is stored correctly, your workflow can use it.

For example:

Webhook
   ↓
Map Lead Type
   ↓
Condition
   ↓
Enterprise?
 ↙       ↘
Yes       No
 ↓         ↓
Sales     Standard

Use mapped webhook data in messages

Suppose the webhook sends:

name = Rahul

You can use the stored customer value in a suitable message.

For example:

Hi Rahul, thanks for your enquiry.

Use mapped data in conditions

Suppose:

lead_type = Enterprise

You can route the conversation differently.

This is where mapping becomes more than simple data storage.

Use mapped data with APIs

Webhook data can also become the input to another API call.

For example:

Webhook
   ↓
Order Number
   ↓
HTTP API
   ↓
Order Status

See How to Use HTTP API in ZazzyAgent Flow Builder.

Use mapped data with labels

Suppose:

lead_type = Enterprise

Your automation can apply an appropriate label.

For example:

Enterprise Lead

Check field types

A common mistake is treating every value as plain text.

For example:

budget

may need to be treated as a number for numeric comparisons.

Likewise:

email

should be stored using an appropriate email field where available.

The field type affects how the data can be validated and used later.

Check nested JSON

External systems don't always send flat data.

You might receive:

{
  "customer": {
    "name": "Rahul",
    "phone": "+919876543210"
  }
}

Here, the information isn't directly at the top level.

You need to understand the payload structure before mapping it.

What if the field is missing?

Your external system may sometimes send:

name
phone

but omit:

email

Don't assume every webhook contains every field.

Your automation should account for missing values.

What if a field is empty?

An empty value is different from a missing value.

For example:

email = ""

means the field exists but contains no value.

You can use conditions or validation where appropriate.

Common mapping mistakes

Correct webhook, wrong field

The request arrived, but you're using the wrong field name.

Phone isn't mapped

ZazzyAgent cannot identify the intended WhatsApp recipient.

Custom field doesn't exist

Create the field before mapping.

Wrong value type

A numeric field may receive unexpected text.

Nested data ignored

The value exists inside another object in the JSON structure.

Test with one customer first

Don't test using 500 live leads.

Send one test request.

Check:

• Correct customer

• Correct name

• Correct phone

• Correct custom fields

• Correct next action

Then move to production.

A useful debugging sequence

Webhook received?
       ↓
Correct payload?
       ↓
Correct field name?
       ↓
Correct destination?
       ↓
Value saved?
       ↓
Next automation uses it?

That sequence tells you where the problem actually is.

The key idea

A webhook delivers the data.

Mapping gives the data meaning inside ZazzyAgent.

Once the mapping is correct, the same information can drive messages, conditions, actions, APIs and customer management.

Ask the customer for information → send that information to another system.

For example:

What's your name?

What's your email?

What service do you need?

After the customer answers, you may want to send the information to your CRM, database or custom application.

The JSON API Connector can be used for this type of outgoing integration.

What we're building

We'll create:

Customer
   ↓
User Input Flow
   ↓
Collect Information
   ↓
JSON API Connector
   ↓
External Webhook
   ↓
External System

Before you start

You need:

• A ZazzyAgent Flow

• User Input fields

• A receiving webhook/API URL

• Access to the JSON API Connector

Step 1: Build your User Input flow

Create a flow that collects the information you need.

For example:

Name

Email

Phone

Requirement

Save each answer to the appropriate system/custom field.

Step 2: Test the User Input first

Before adding the API integration, make sure the flow successfully stores the customer responses.

This gives you a known-good starting point.

Step 3: Prepare the external endpoint

Create the endpoint that will receive your JSON data.

For testing, you can use a webhook inspection service.

For production, use your own secure API/webhook endpoint.

Step 4: Open JSON API Connector

Open the JSON API Connector in ZazzyAgent.

Create a new connector.

Step 5: Name the connector

Use a meaningful name.

For example:

CRM – Lead Submission

This makes it clear what the connector does.

Step 6: Add your webhook URL

Enter the external URL that should receive the data.

For example:

https://example.com/api/leads

Use your actual endpoint.

Step 7: Choose the trigger

Select:

User Input Flow

Then select the Flow that collects your lead information.

This tells ZazzyAgent:

When this particular input flow completes, send the selected data.

Step 8: Select the fields

Choose the information you want to send.

For example:

• First Name

• Email

• Phone

• Requirement

• Budget

The connector can send system fields as well as customer/user-input information. (botsailor.com)

Step 9: Save

Save the connector.

Step 10: Run a test

Start your User Input flow.

Enter test information:

Rahul

rahul@example.com

+919XXXXXXXXX

WhatsApp automation

Then check your receiving endpoint.

Step 11: Inspect the request

You should see the information in JSON form.

The exact structure depends on your selected fields and ZazzyAgent's current payload format.

Example business workflow

Suppose your sales team uses a CRM.

Your ZazzyAgent lead flow collects:

Name
Email
Phone
Requirement
Budget

When the form finishes:

User Input Complete
        ↓
JSON API Connector
        ↓
CRM API
        ↓
New Lead

Now your sales team doesn't need to manually copy the lead.

Use it with Instagram leads

An Instagram AI Agent may qualify a customer.

Once the required information has been collected:

Instagram
    ↓
AI Agent
    ↓
Lead Qualification
    ↓
User Input / Saved Data
    ↓
JSON API
    ↓
CRM

The same architecture can be used for WhatsApp or other supported channels.

Use it with website leads

A website isn't the only place where this approach works.

Any ZazzyAgent conversation that produces structured information can potentially feed an external system.

Send only the necessary data

Suppose the CRM only requires:

• Name

• Email

• Phone

Don't send twenty unrelated fields.

Smaller payloads are easier to maintain.

Keep your external endpoint stable

Don't change your endpoint URL casually after the connector is configured.

If the destination changes, update the connector and test it again.

What if the external system doesn't receive anything?

Check in this order:

1. User Input completed

Did the customer actually reach the end of the form?

2. Connector is active/configured

Is the correct connector attached to the intended User Input Flow?

3. URL

Is the webhook/API URL correct?

4. Endpoint

Is the receiving server online?

5. Payload

Did the request contain the expected fields?

What if some fields are empty?

Check whether:

• Customer actually provided them.

• The field is mapped correctly.

• The field is the correct system/custom field.

• The User Input question saves the answer correctly.

What if you need custom authentication?

If the receiving API requires authentication features that the JSON API Connector doesn't directly provide, use a secure backend relay.

For example:

ZazzyAgent
   ↓
Your secure webhook
   ↓
Authenticated server-side API call
   ↓
CRM

This avoids placing private API credentials in the customer-facing automation.

Test with a real-looking payload

Don't test only:

Test User

Use realistic values.

That lets you discover:

• Field formatting problems

• Phone-number issues

• Empty values

• Unexpected characters

• CRM validation errors

Add error handling

Your external system can fail.

For example:

• Server unavailable

• Invalid request

• CRM error

• Duplicate lead

• Authentication failure

Your business should decide what happens when that occurs.

Don't tell the customer the API failed

Avoid:

HTTP 500

Instead:

We've received your information. Our team will process it shortly.

Then let your technical system handle the failure internally.

The final architecture

Customer
   ↓
User Input
   ↓
Validate
   ↓
Save Fields
   ↓
JSON API Connector
   ↓
External System
   ↓
CRM / Database / Application

This is one of the simplest ways to turn a ZazzyAgent conversation into an automated business process.

One of the integration options designed for this is the JSON API Connector.

It is useful when you want to take information collected by a ZazzyAgent flow and send it to another system as JSON.

What does the JSON API Connector do?

The connector sends structured JSON data to a URL you provide.

For example:

Customer
   ↓
ZazzyAgent User Input
   ↓
JSON API Connector
   ↓
Your Webhook
   ↓
Your Application

The receiving application can then process the information.

What is JSON?

JSON is a structured way of representing data.

For example:

{
  "name": "Rahul",
  "email": "rahul@example.com",
  "budget": "75000"
}

A receiving system can read these values programmatically.

When should you use the JSON API Connector?

Use it when an external system needs customer data from ZazzyAgent.

Examples:

• CRM integration

• Lead processing

• Internal applications

• Database workflows

• Custom backend automation

• External notification systems

• Zapier/automation workflows

The current connector documentation specifically describes sending User Input data to an external webhook URL as JSON. (botsailor.com)

JSON API Connector vs HTTP API

These are easy to confuse.

HTTP API

ZazzyAgent calls an external API.

ZazzyAgent
   ↓
External API

JSON API Connector

ZazzyAgent sends customer/event data to the configured endpoint.

ZazzyAgent
   ↓
Webhook / External System

The key question is:

Who is initiating the request?

Typical JSON API workflow

A common setup is:

User Input Flow
       ↓
Customer provides data
       ↓
JSON API Connector
       ↓
External webhook
       ↓
Your system processes data

Step 1: Create your User Input Flow

Build a flow that collects the information you need.

For example:

Name

Email

Phone

Requirement

Save those responses.

Step 2: Create your receiving endpoint

Your external application needs a URL that can receive the JSON request.

For testing, you can use a webhook inspection service or your own endpoint.

Step 3: Create the JSON API connection

Open the JSON API Connector in ZazzyAgent.

Create a connection.

Give it a clear name.

For example:

CRM Lead Submission

Step 4: Enter the webhook URL

Paste the URL where ZazzyAgent should send the JSON data.

Step 5: Select the trigger

Choose the relevant User Input Flow as the trigger.

This tells ZazzyAgent when to send the data.

Step 6: Choose the fields

Select the information you want to send.

For example:

• First Name

• Last Name

• Email

• Phone

• User Input fields

The current connector allows you to select system fields, custom/user-input data or both. (botsailor.com)

Step 7: Save the configuration

Save the connector after configuring it.

Step 8: Test the flow

Start your User Input flow.

Answer the questions.

Then inspect the receiving endpoint.

You should see the JSON request.

Example

Customer provides:

Name: Rahul

Email: rahul@example.com

Requirement: WhatsApp automation

The receiving system may get:

{
  "first_name": "Rahul",
  "email": "rahul@example.com",
  "requirement": "WhatsApp automation"
}

The exact payload depends on the fields you've selected and your ZazzyAgent configuration.

What can your external system do?

After receiving the data, your application can:

• Create a CRM lead

• Store a database record

• Send an internal notification

• Trigger another workflow

• Start an email process

• Create a task

ZazzyAgent doesn't need to do everything itself.

The connector lets another application take over after the data is collected.

Use JSON API with lead qualification

A lead agent can collect:

• Name

• Requirement

• Budget

• Timeline

Then the connector sends the information to your CRM.

Instagram / WhatsApp
       ↓
AI / Flow
       ↓
Lead Qualification
       ↓
User Input
       ↓
JSON API
       ↓
CRM

Use it with surveys

A survey can collect:

• Rating

• Feedback

• Comment

The connector sends those answers to your database or analytics system.

Use it with custom applications

This is especially useful if your business has software that isn't available as a native ZazzyAgent integration.

You can build a receiving endpoint and let ZazzyAgent send the data there.

What about authentication?

The current JSON API Connector documentation describes sending data to public or pre-authenticated endpoints through the connector. If your system requires custom authentication headers or tokens that the connector does not support directly, a secure backend relay is the safer architecture. (botsailor.com)

Don't expose private credentials inside customer-facing flow messages.

JSON API Connector vs Webhook Workflow

These features can sound similar.

A Webhook Workflow is typically used to receive data/event information from another system and then start an automation in ZazzyAgent.

A JSON API Connector is used to send structured ZazzyAgent/customer data outward to a configured endpoint.

Think:

Webhook Workflow = incoming data

JSON API Connector = outgoing data

JSON API vs Google Sheets

Use Google Sheets when a spreadsheet is the destination and suits the workflow.

Use JSON API when you need programmatic integration with another application.

Test before going live

Always send a test submission.

Verify:

• Request arrives

• JSON is valid

• Correct fields are included

• Values are correct

• External system processes them correctly

Keep the payload small

Only send information the receiving system needs.

There's no reason to send every available customer field if the receiving application only needs five.

Name integrations clearly

Good:

CRM – New Lead

Booking System – Appointment Request

Poor:

Test JSON

Clear names make maintenance much easier.

The simplest mental model

Remember:

Collect information
       ↓
Turn it into JSON
       ↓
Send it outward
       ↓
External system processes it

That's the main purpose of the JSON API Connector.

For example, a lead form might need:

1. Name

2. Email

3. Requirement

4. Budget

5. Timeline

You can build this as a conversational multi-step form in ZazzyAgent.

The customer answers one question at a time and the flow moves to the next step.

What is a multi-step form?

A multi-step form is a series of User Input questions.

The architecture is:

Question 1
    ↓
Answer
    ↓
Question 2
    ↓
Answer
    ↓
Question 3
    ↓
Answer
    ↓
Confirmation

The current User Input documentation supports collecting several fields in sequence and saving their answers to system or custom fields. (botsailor.com)

When should you use one?

Use a multi-step form when you need several pieces of information but want the customer to provide them conversationally.

Examples:

• Lead qualification

• Appointment requests

• Support requests

• Registration

• Surveys

• Quote requests

Step 1: Decide what you need

Start with the end result.

For example:

Sales team needs a qualified lead.

What information do they actually need?

Perhaps:

• Name

• Email

• Service

• Budget

• Timeline

That's your form.

Step 2: Create the first question

Ask:

What's your name?

Save the answer into the appropriate name field.

Step 3: Ask for email

Next:

What's the best email address to reach you?

Use the appropriate email input type.

Step 4: Ask about the requirement

For example:

What are you looking for?

Save the response to:

Requirement

Step 5: Ask the budget

For example:

What's your approximate budget?

Save to:

Budget

Step 6: Ask about timing

For example:

When are you hoping to get started?

Save to:

Timeline

Step 7: Confirm the information

At the end, send a confirmation.

For example:

Thanks, Rahul. I've recorded your requirement and budget. We'll use these details to help with the next step.

Step 8: Trigger the next automation

After the form, you can:

• Add a label

• Assign a sequence

• Call an API

• Trigger another flow

• Assign a human

• Transfer to an AI Agent

The correct action depends on your process.

Example: Lead qualification form

Name
 ↓
Email
 ↓
Requirement
 ↓
Budget
 ↓
Timeline
 ↓
Confirmation
 ↓
Qualified Lead

Example: Support form

Name
 ↓
Issue Type
 ↓
Order Number
 ↓
Problem Description
 ↓
Confirmation
 ↓
Support Team

Example: Appointment form

Name
 ↓
Service
 ↓
Preferred Date
 ↓
Preferred Time
 ↓
Confirmation

Don't ask everything at once

A message such as:

Please send your name, email, phone, company, requirement, budget and preferred date.

creates unnecessary work for the customer.

One question at a time is easier to complete and validate.

Use Quick Replies where possible

Suppose the customer needs to choose:

What service do you need?

Use:

Consultation

Demo

Installation

instead of forcing them to type.

Then use User Input for information that needs free text.

Use validation

Each important input should use appropriate validation.

Examples:

Email

→ Email validation

Phone

→ Phone formatting

Budget

→ Numeric validation where appropriate

Save every answer

Give every important answer a destination.

For example:

Name       → First Name
Email      → Email
Requirement → Custom Field
Budget     → Custom Field
Timeline   → Custom Field

Don't overwrite unrelated fields

Make sure each question saves into its intended destination.

Accidentally saving:

Budget

into:

City

can create confusing customer records.

Use conditions after the form

Suppose:

Budget = 100000

After collecting the form:

Budget ≥ 100000
       ↓
Enterprise Sales

Otherwise:

Standard Sales.

Use labels after the form

You could add:

Qualified Lead

once all required information has been captured.

Send data to your CRM

Once the form is complete, use HTTP API or another integration method to send the information to your external system.

For example:

Multi-Step Form
      ↓
Customer Data
      ↓
HTTP API
      ↓
CRM

Don't make forms too long

A ten-question form may be appropriate for some businesses.

But if customers repeatedly abandon it, reduce the number of questions.

Only ask for information that changes what happens next.

Give customers progress context

When appropriate, tell customers what they're doing.

For example:

Great. Just two more questions and we'll have everything we need.

This helps them understand why the conversation continues.

Handle incomplete conversations

Customers may stop answering halfway through.

Design your follow-up strategy appropriately.

Don't assume every customer completes every step.

Test the complete form

Test:

• Correct answers

• Invalid answers

• Missing answers

• Early abandonment

• Each saved field

• Confirmation

• Final automation

Multi-step form vs WhatsApp Flow

Use a conversational multi-step form when:

One question at a time works well.

Use a WhatsApp Flow when:

A structured form interface is more convenient.

Both can be valuable.

The architecture

Start
 ↓
Input
 ↓
Validate
 ↓
Save
 ↓
Input
 ↓
Validate
 ↓
Save
 ↓
...
 ↓
Complete
 ↓
Automation

Once you understand this pattern, you can build lead forms, booking requests, support intake forms and surveys without creating a separate manual process for each one.

Suppose your flow asks:

What's your email address?

A customer accidentally types:

rahul@

If your automation accepts it without validation, the bad value can later be sent to your CRM, API or sales team.

Validation helps prevent that.

What is input validation?

Validation checks whether the customer's response matches the rules you've defined.

For example:

Email must be a valid email address.

or:

Age must be a number.

The current User Input functionality provides validation rules for supported input types. (botsailor.com)

Why validation matters

Without validation:

Customer
   ↓
Bad data
   ↓
CRM / API
   ↓
Problem later

With validation:

Customer
   ↓
Validate
   ↓
Valid → Save
Invalid → Ask again

Required vs optional

These are different concepts.

Required

Customer must provide an answer.

Example:

Name

Optional

Customer can continue without answering.

Example:

Additional comments

Only make fields required when your workflow actually needs them.

Validate email addresses

If the field is intended to collect email, use the appropriate email input type or validation.

A valid example:

rahul@example.com

An invalid example:

rahul@

This prevents obvious formatting problems.

Validate phone numbers

Phone numbers need careful handling.

Decide what format your business expects.

For WhatsApp-related workflows, international formatting is often important.

For example:

+919XXXXXXXXX

Rather than an ambiguous local format.

Validate numbers

Suppose you ask:

What is your budget?

You probably want a number.

A response such as:

Maybe around fifty thousand

is different from:

50000

Consider whether your workflow needs strict numeric input or whether free text is more appropriate.

Set minimum and maximum values

For fields that represent numbers or lengths, use sensible limits where supported.

Example:

Company size must be greater than 0.

or:

PIN must contain exactly 6 digits.

The exact available validation controls depend on the input type.

Validate text length

Some information shouldn't be extremely short.

For example:

Describe your requirement.

A one-character answer may not be useful.

You can use appropriate length rules where supported.

Invalid response message

A customer should understand what went wrong.

Bad:

Invalid input.

Better:

Please enter a valid email address, such as name@example.com.

The message should explain what the customer needs to correct.

Let customers try again

A validation failure shouldn't end the conversation.

The usual structure is:

Question
   ↓
Customer answer
   ↓
Valid?
 ↙      ↘
Yes      No
 ↓        ↓
Save   Explain + retry

Example: Email

Enter your email address.
        ↓
User Input
        ↓
Valid?
 ↙       ↘
Yes       No
 ↓         ↓
Save      "Please enter a valid email."

Example: OTP/PIN

If you're asking for a fixed-length value:

Enter your 6-digit PIN.

You can validate the expected number and length where the input configuration supports it.

Example: Age

If your process requires an age:

Enter your age.

Your validation rules can prevent obviously invalid values.

Validation before an API

This is especially important.

Imagine:

Customer enters Order ID
        ↓
Validation
        ↓
HTTP API

The API only receives a value that meets your input requirements.

This reduces unnecessary API calls and bad requests.

Validation before CRM submission

The same principle applies when sending leads to a CRM.

Don't send:

invalid-email@

to your external system and discover the problem later.

Validate first.

Validation and User Input

Validation is part of the data-collection process.

A useful architecture is:

Ask
 ↓
Collect
 ↓
Validate
 ↓
Save
 ↓
Use

Don't over-validate

Validation should prevent bad data, not make the form impossible to complete.

For example, if a customer says:

My budget is around ₹50,000.

and your workflow doesn't require a strict number, don't force them through a rigid numeric field unnecessarily.

Use the least restrictive format that still gives you usable information.

Test invalid answers

Don't test only the correct answer.

For every important field, test:

Correct

Empty

Too short

Too long

Wrong format

Unexpected value

Common validation problems

Correct input is rejected

Your validation rule may be too restrictive.

Invalid input is accepted

The validation may not match the actual data requirement.

Customer gets stuck

Check that the invalid path lets them try again.

Data is saved incorrectly

Check the input type and destination field.

Good validation design

The customer should know:

What information do you need?

What format should I use?

What happens if I make a mistake?

That is much better than silently rejecting input.

The rule to remember

Validate data at the point where you collect it.

Fixing bad customer data later is usually harder than preventing it in the first place.

Instead of only saying:

Welcome! How can I help?

you can ask:

What is your name?

What service are you interested in?

What is your budget?

What is your email address?

ZazzyAgent's User Input functionality lets a flow collect these answers and use them later in the automation.

What is User Input?

User Input is a component that pauses a conversation, asks the customer for information and saves the response.

The basic pattern is:

Question
   ↓
Customer responds
   ↓
User Input
   ↓
Save response
   ↓
Next step

What can you collect?

Depending on the configuration, you can collect information such as:

• Text

• Email

• Phone number

• Numbers

• Other supported input types

The available input types depend on the current User Input configuration.

Example: Lead form

You could ask:

What is your name?

Customer:

Rahul

Then:

What's your email?

Customer:

rahul@example.com

Then:

What are you looking for?

Customer:

WhatsApp automation.

The flow now has useful structured information about the lead.

Why save the response?

If you only display the question and don't save the answer, that information has limited value.

Saving it allows later parts of your automation to use the customer's response.

For example:

User Input
   ↓
Budget = 75000
   ↓
Condition
   ↓
Budget > 50000

Now the conversation can branch according to the customer's answer.

User Input vs a normal message

These are different.

Normal message

What is your budget?

The bot asks a question but doesn't necessarily collect it into a structured field.

User Input

What is your budget?

Customer answers.

ZazzyAgent captures the answer and saves it according to your configuration.

User Input vs Quick Reply

Use Quick Reply when the customer should choose from predefined options.

Example:

Small

Medium

Large

Use User Input when the customer needs to provide their own answer.

Example:

What is your budget?

Customer types:

₹75,000

User Input vs WhatsApp Flow

A User Input step is useful for collecting individual answers within a conversation.

A WhatsApp Flow is better when you want a more structured form experience with multiple fields and screens.

Both solve data-collection problems, but they provide different customer experiences.

Save to a system field

Some inputs can be saved to existing customer information fields.

For example:

• Name

• Email

• Phone

Where the appropriate system field is available, use it rather than creating unnecessary custom fields.

Save to a custom field

For business-specific information, use custom fields.

Examples:

Budget

City

Property Type

Preferred Date

Requirement

See ZazzyAgent Custom Fields Guide.

Example: Lead qualification

What service do you need?
      ↓
User Input
      ↓
Save: Service Interest

What is your budget?
      ↓
User Input
      ↓
Save: Budget

When do you want to start?
      ↓
User Input
      ↓
Save: Timeline

Those values can then be used by your AI Agent, conditions, labels and other automation.

Use User Input with conditions

Suppose you ask:

How many employees are in your company?

Customer:

250

Save:

Company Size = 250

Then:

Company Size > 100
        ↓
Enterprise Lead

Otherwise:

Standard Lead

Use User Input with labels

A customer could answer:

I need a demo.

Your automation can save the response and then add a suitable label.

This turns conversational information into structured customer data.

Use User Input with sequences

After collecting a customer's information, you can start a relevant sequence.

For example:

Product Interest = Enterprise

↓

Start:

Enterprise Follow-up

Use User Input with APIs

User Input becomes especially powerful when combined with HTTP APIs.

For example:

Customer enters Order Number
          ↓
Save Order Number
          ↓
HTTP API
          ↓
Check Order
          ↓
Customer receives status

See How to Use HTTP API in ZazzyAgent Flow Builder.

Use the right question for the field

Bad:

Tell us your information.

Better:

What is your company name?

Specific questions produce better data.

Don't collect unnecessary information

Every question adds friction.

Before adding a field, ask:

Will my business use this information?

If not, remove it.

Use validation

If you're collecting an email address, use an email input/validation configuration rather than accepting anything as text.

If you're collecting a number, configure it appropriately.

See How to Validate User Input in ZazzyAgent.

What happens if the customer gives invalid information?

Your flow should handle it properly.

For example:

Please enter a valid email address.

Then let the customer try again.

Multi-step data collection

User Input can be used several times in the same flow.

For example:

Name
 ↓
Email
 ↓
Phone
 ↓
Requirement
 ↓
Budget
 ↓
Confirmation

This creates a simple conversational form.

User Input and AI

An AI Agent and User Input can work together.

For example, the AI can understand that a customer has already provided their:

Name

and avoid asking for it again.

The structured data remains useful for your automations.

Test User Input

Test every field.

Check:

• Question

• Input type

• Saved field

• Validation

• Next step

• Invalid response behavior

The basic rule

Remember:

Message = tell the customer something.

Quick Reply = let the customer choose.

User Input = collect information.

Once you understand that distinction, building data-driven flows becomes much easier.

Don't create another catalog immediately.

First identify where the connection breaks.

The basic chain is:

Meta Business
      ↓
Catalog
      ↓
WhatsApp Business Account
      ↓
ZazzyAgent
      ↓
Flow Builder
      ↓
Catalog Component

Problem 1: Catalog doesn't exist in Meta

Open your Meta commerce/catalog area.

Confirm that the catalog exists.

If it doesn't, create and populate the catalog first.

Problem 2: Catalog exists but has no products

Open the catalog.

Check whether the products are actually there.

A catalog with no products won't give your Flow Builder anything useful to display.

Problem 3: Wrong Meta business

Businesses sometimes have multiple Meta business environments.

Make sure the catalog belongs to the business connected to your WhatsApp setup.

Problem 4: Wrong WhatsApp Business Account

Your ZazzyAgent WhatsApp connection needs to be associated with the correct WhatsApp Business Account.

If you manage multiple WABAs, verify which one contains the relevant phone number and commerce setup.

Problem 5: Catalog permissions

Check your Meta account's access to:

• Business

• Catalog

• WhatsApp Business Account

If you can see a catalog in one Meta account but authorize ZazzyAgent using another account, the expected catalog may not appear.

Problem 6: WhatsApp isn't connected correctly

Confirm that the correct WhatsApp account is connected to ZazzyAgent.

See:

Can't Connect WhatsApp to ZazzyAgent? Troubleshooting Guide.

Problem 7: Catalog exists but doesn't appear in ZazzyAgent

Check the connection/synchronization state.

Refresh the relevant ZazzyAgent page.

Then verify that you're working with the correct connected WhatsApp account.

Problem 8: Wrong catalog selected

If multiple catalogs exist, check which one is configured in the Catalog component.

You may simply be looking at a different catalog.

Problem 9: Catalog appears but products don't

Open the catalog in Meta.

Check:

• Product exists

• Product is active/available

• Product belongs to the correct catalog

• Product information is complete

The current catalogue flow requires products to exist in the connected catalog before they can be selected in the Flow Builder.

Problem 10: Product was recently added

If you've just added a product, allow the catalog information to synchronize before assuming the integration is broken.

Then refresh the catalog/product selection.

Problem 11: Product was changed but old information appears

Check the catalog itself first.

The product information comes from the catalogue.

Don't immediately rewrite the Flow.

Problem 12: Catalog works outside the Flow but not inside it

Check the Flow Builder configuration.

Make sure the structure is:

Interactive Message
       ↓
Catalog

The current catalogue setup uses the Interactive Template's ecommerce connection to add the Catalog component.

Problem 13: Catalog component doesn't appear

Check whether you're adding it from the appropriate Interactive/ecommerce section.

Don't look for it among unrelated standard text elements.

Problem 14: Flow works but catalog doesn't display

Test the Flow in isolation.

Use a simple flow:

Trigger
 ↓
Interactive
 ↓
Catalog

If that works, the problem is probably somewhere else in your larger flow.

Problem 15: Some products appear and others don't

Compare the products inside Meta.

Check whether the missing products:

• Belong to the selected catalog

• Are available for the connected setup

• Have complete product information

• Are being selected in the intended product section

Problem 16: The wrong product section appears

Check your multiple-product configuration.

You may have connected a different section or product group than intended.

Problem 17: Catalog is correct but customers don't see it

Test the actual WhatsApp conversation.

Don't rely only on the Flow Builder preview.

Check:

Flow executes

→ Interactive message arrives

→ Catalog appears

→ Product appears

→ Customer can interact

Troubleshoot in order

Use this sequence:

Meta

Does the catalog exist?

↓

Products

Are the products inside it?

↓

WhatsApp

Is the correct WABA connected?

↓

ZazzyAgent

Is the correct WhatsApp account connected?

↓

Flow

Is the Catalog component correctly configured?

↓

Customer

Does the actual WhatsApp message display correctly?

Don't change multiple things simultaneously

Suppose the catalog isn't showing.

Don't:

• Create a new catalog.

• Reconnect WhatsApp.

• Delete your Flow.

• Create new products.

• Change Meta permissions.

all at once.

You'll lose track of what actually fixed the problem.

Change one thing, test, then continue.

Quick checklist

Meta

• [ ] Correct business

• [ ] Catalog exists

• [ ] Products exist

WhatsApp

• [ ] Correct WABA

• [ ] Correct phone number

• [ ] Correct permissions

ZazzyAgent

• [ ] Correct WhatsApp account connected

• [ ] Catalog available

• [ ] Correct catalog selected

Flow Builder

• [ ] Interactive component exists

• [ ] Catalog connected

• [ ] Correct products selected

• [ ] Flow saved

Testing

• [ ] Flow triggered

• [ ] Catalog displayed

• [ ] Products displayed

• [ ] Customer interaction works

The most important diagnostic rule

When a catalog isn't working, separate:

Catalog problem

from:

Flow problem

If the catalog itself is wrong, fix Meta.

If the catalog is correct but the Flow isn't displaying it, fix the ZazzyAgent configuration.

That distinction saves a lot of unnecessary troubleshooting.

For more help contact: ZazzyAgent Support

This allows customers to browse products as part of a conversation.

A simple flow can look like:

Customer
   ↓
Trigger
   ↓
Interactive Message
   ↓
Catalog
   ↓
Product Selection
   ↓
Next Step

Before you begin

Make sure:

• WhatsApp is connected.

• Your catalog exists.

• Products have been added.

• The catalog is available to the connected WhatsApp account.

See How to Connect a WhatsApp Catalog to ZazzyAgent.

Step 1: Create a Flow

Open Flow Builder.

Create a new flow.

Give it a useful name.

For example:

Product Catalogue

rather than:

Test 7

Step 2: Add a trigger

Choose the appropriate trigger for your flow.

For example:

products

This lets a test customer start the flow by sending:

products

Step 3: Add an Interactive Message

Add the appropriate Interactive Template/message component.

This provides the introductory part of the catalog experience.

Example:

Here are some of our available products.

Step 4: Connect the Catalog

Use the ecommerce/catalog connection from the interactive component.

Add the Catalog component.

The current configuration workflow connects the interactive component's ecommerce section to the Catalog element.

Step 5: Select your catalog

Open the Catalog component.

Choose the catalog you've connected to your WhatsApp setup.

Step 6: Choose how many products to show

You can configure the catalogue to present individual products or multiple products.

Single product

Use when you know exactly which product should be displayed.

Multiple products

Use when customers need to browse several products.

The current catalogue component supports both approaches.

Example: One product

Customer:

Tell me about Product A.

Your flow:

Customer
   ↓
Product A
   ↓
Catalog
   ↓
Product A

The customer sees the relevant product from the connected catalog.

Example: Multiple products

Customer:

Show me your products.

Your flow displays several products.

The customer can browse them and select the one they're interested in.

Step 7: Create the next step

Think about what should happen after the customer interacts with the catalog.

For example:

Product selected

→ Send additional information

or:

Product selected

→ Start another flow

or:

Product selected

→ Continue to an AI assistant

The right choice depends on your use case.

Example: Product information

Catalog
   ↓
Customer selects product
   ↓
Product information
   ↓
Ask if they need help

Example: Lead generation

A customer sees a service/product.

Then:

Would you like a quotation?

Yes

→ Lead form.

No

→ Continue browsing.

Example: AI-assisted product enquiry

Customer
   ↓
AI Agent
   ↓
Understands interest
   ↓
Relevant catalog
   ↓
Customer selects product
   ↓
Continue conversation

This can make the catalog feel like part of a conversational shopping assistant.

Don't duplicate the catalog into your flow

The purpose of using the Catalog component is to reference the structured catalog.

Don't manually recreate all product information in text nodes unless there's a specific reason.

Update products in the catalog

If:

Product A price changes.

update Product A in your connected catalog.

Your Flow doesn't need to become a second product database.

Multiple product sections

For broader catalog presentations, organize products logically.

For example:

Shoes

Shirts

Accessories

Instead of showing unrelated products all at once.

The current catalogue workflow supports product sections and multiple-product configurations.

Use the catalog after a category selection

A useful pattern is:

What are you looking for?
       ↓
[Shoes]
[Clothing]
[Accessories]
       ↓
Relevant Catalog

This creates a much cleaner customer experience than displaying your entire catalog immediately.

Catalog and customer intent

A catalog should appear at the right point in the conversation.

Don't send a product catalog to someone who is asking:

How do I contact support?

Use conditions, routing or AI to determine whether the customer is actually looking for products.

Test the flow

Test:

• Trigger

• Interactive message

• Catalog

• First product

• Other products

• Next step

Make sure each path behaves correctly.

Common problems

Catalog component is empty

Check the connected catalog and Meta access.

Product isn't available

Check whether the product belongs to the selected catalog.

Wrong product appears

Check your product selection in the Catalog configuration.

Updated product information isn't showing

Check the catalog itself and allow the updated information to propagate.

A clean architecture

Customer Intent
      ↓
Flow
      ↓
Interactive Message
      ↓
Catalog
      ↓
Relevant Product(s)
      ↓
Customer Selection
      ↓
Next Automation

The Catalog should be treated as a structured data source inside your conversational workflow—not as a replacement for the Flow Builder itself.

The overall process is:

Meta Business
     ↓
Commerce Catalog
     ↓
Products
     ↓
WhatsApp Business Account
     ↓
ZazzyAgent
     ↓
Flow Builder

Before you start

You should have:

• A Meta business environment

• A connected WhatsApp Business Account

• Access to the relevant business assets

• Products you want to display

Your Meta permissions need to be sufficient to manage the relevant catalog/business assets.

Step 1: Open Meta Commerce Manager

Log in to the Meta business environment that manages your business assets.

Open the commerce/catalog management area.

The exact navigation can change as Meta updates its interface, so look for the current Commerce Manager or Catalog area.

Step 2: Create or select a catalog

If you already have a catalog, use the existing one.

You don't need to create a new catalog simply because you're connecting ZazzyAgent.

If you don't have one, create a catalog appropriate for your business.

Step 3: Add your products

Add the products you want customers to see.

Depending on your setup, product information can include:

• Name

• Price

• Description

• Images

• Product link

• Product ID

Make sure the product information is accurate before testing it in ZazzyAgent.

Step 4: Check your business permissions

Make sure the business and catalog are accessible to the Meta account you're using.

If the catalog exists but isn't available during connection, don't immediately create another one.

First check permissions and business ownership.

Step 5: Check your WhatsApp Business Account

Your WhatsApp business setup needs access to the appropriate catalogue.

The catalog and WhatsApp business configuration need to be associated correctly before ZazzyAgent can use the products.

Step 6: Connect WhatsApp to ZazzyAgent

Your WhatsApp account should already be connected to ZazzyAgent.

If it isn't, start with:

How to Get WhatsApp API and Connect WhatsApp to ZazzyAgent.

Step 7: Open the catalog area in ZazzyAgent

Once your WhatsApp account is connected, open the relevant catalogue/ecommerce area inside ZazzyAgent.

The connected catalog should become available for use.

The current platform workflow provides an ecommerce catalog area associated with the connected WhatsApp setup.

Step 8: Select the catalog

If multiple catalogs are available, choose the one containing the products you want to use.

Double-check the selection.

Businesses can have multiple catalogs for different purposes.

Step 9: Create a test Flow

Don't immediately put the catalog into your main production automation.

Create a small test flow.

For example:

Send catalog

↓

Show catalog.

This lets you verify the connection without disturbing your existing customer journey.

Step 10: Add an Interactive Message

Open Flow Builder.

Create or open the test flow.

Add the appropriate Interactive Template/message component.

The current catalogue workflow uses an Interactive Template as the entry point before connecting the ecommerce/catalog component.

Step 11: Add the Catalog component

From the appropriate interactive/ecommerce connection point, add the Catalog component.

Open its configuration.

Step 12: Select your connected catalog

Choose the catalog you connected earlier.

You should then be able to configure the products you want to present.

Step 13: Select products

Depending on the flow design, you can present:

• One product

• Multiple products

• A particular group of products

The current Flow Builder catalogue configuration supports single and multiple product selections.

Step 14: Save the flow

Save your flow.

Check the entire connection:

Trigger
 ↓
Interactive Message
 ↓
Catalog
 ↓
Product

Step 15: Test from WhatsApp

Send the trigger message from a test WhatsApp account.

Confirm that the catalogue content appears.

Then interact with the product.

Check the product information

Verify:

• Image

• Product name

• Price

• Description

• Product selection

If something is wrong, first check the catalog itself.

Don't assume the Flow Builder created the product information.

Catalog connection troubleshooting

Catalog doesn't appear

Check:

• Correct Meta Business

• Correct WhatsApp Business Account

• Catalog permissions

• Catalog ownership/access

• WhatsApp connection

Catalog appears but products are missing

Check whether those products actually belong to the selected catalog.

Product information is outdated

Update the product in the catalog rather than recreating the flow.

Wrong catalog appears

Check which Meta business/catalog was selected during setup.

Don't create duplicate catalogs

If you already have a working catalog, reuse it unless there's a real business reason to create another.

Multiple duplicate catalogs can make product management confusing.

Keep one source of truth

A good setup is:

Meta Catalog
    ↓
Products
    ↓
ZazzyAgent
    ↓
Multiple Flows

Instead of:

Flow 1 → Product data
Flow 2 → Product data
Flow 3 → Product data

The first architecture is much easier to maintain.

After the connection works

You can use the catalog in more advanced flows such as:

Customer asks about a product.

↓

AI/Flow determines the relevant category.

↓

Catalog presents the available products.

↓

Customer selects a product.

↓

Next step provides information or continues the configured journey.

That's where the catalogue becomes part of a broader conversational system rather than simply a product list.

Instead of manually sending:

Product photo

Product name

Price

Description

one message at a time, you can connect a Meta/WhatsApp catalog to ZazzyAgent and use it inside your automated conversations.

Customers can browse products and interact with them directly from WhatsApp.

What is the Catalog?

A catalog is a collection of products managed through Meta's commerce tools and associated with your WhatsApp business setup.

A product can contain information such as:

• Product name

• Product image

• Description

• Price

• Product identifier

• Other catalogue information

ZazzyAgent can use the connected catalog inside supported WhatsApp automation.

Why connect a catalog to ZazzyAgent?

The catalog gives your chatbot access to a structured product presentation.

For example:

Customer:

Show me your products.

Your flow can display:

Product A

Product B

Product C

The customer doesn't have to ask for each product separately.

Catalog vs images

You could simply send product images.

But an image is just an image.

A catalog product contains structured product information that can be presented through WhatsApp's commerce experience.

That's useful when customers want to browse actual products rather than look at a collection of unrelated images.

Catalog vs Carousel

These are different features.

Carousel

You manually configure cards in the flow.

Each card can contain content and an action.

Catalog

Products come from your connected WhatsApp catalog.

This makes catalog particularly useful when your products are already maintained in Meta's commerce environment.

Where does the catalog come from?

The catalog is managed through Meta's commerce infrastructure.

ZazzyAgent connects to the appropriate WhatsApp/Meta business setup and can then use the catalog in supported flows.

You don't normally create every product again inside every bot flow.

What does ZazzyAgent do?

ZazzyAgent gives your automation a way to use the catalog inside a customer conversation.

For example:

Customer
   ↓
ZazzyAgent Flow
   ↓
Catalog
   ↓
Products
   ↓
Customer selects product

When should I use a catalog?

A catalog works well when customers need to browse products.

Examples:

• Clothing

• Electronics

• Furniture

• Food products

• Beauty products

• Accessories

• Consumer goods

It can also be useful for services or offerings that can be represented as catalog items, depending on your business setup.

Do I need a catalog before using the Catalog component?

Yes.

The Catalog component needs a connected catalog to display products.

You should first make sure your WhatsApp catalog exists and contains the products you want to show.

The current setup documentation requires the catalog to be created before connecting and using it in a flow.

Can I show every product?

You can configure the catalogue experience to show the products or product sections appropriate for the flow.

You don't have to send your entire product catalogue every time.

For example:

Customer asks about shoes.

Your flow can present the relevant products rather than unrelated items.

Single product vs multiple products

The Catalog component supports selecting individual products as well as using a multiple-products configuration.

Single product

Useful when:

Customer asks about one specific product.

Multiple products

Useful when:

Customer wants to browse several options.

The current flow configuration supports both individual and multiple-product selections.

Example: Product enquiry

Customer:

Do you have running shoes?

Your flow can display relevant products from the connected catalog.

The customer can then explore the available product information.

Example: Product menu

Your flow could begin:

What are you looking for?

Shoes

Clothing

Accessories

Customer selects:

Shoes

↓

Show relevant catalog products.

This keeps the initial conversation simple.

Catalog and AI

The catalog can also work alongside an AI Agent.

For example:

Customer:

I'm looking for a black running shoe under ₹5,000.

The AI can understand the customer's request.

Your workflow can then guide the customer toward relevant product information or catalog content where your configured setup supports it.

The catalog provides the structured product data; the AI provides conversational understanding.

Catalog and Flow Builder

A common architecture is:

Trigger
   ↓
Interactive Message
   ↓
E-commerce / Catalog
   ↓
Products

The current Flow Builder reference uses an Interactive Template and then connects its ecommerce socket to the Catalog component.

Catalog information should stay in the catalog

Don't manually copy every product's:

• Name

• Price

• Image

• Description

into dozens of different bot flows.

Whenever possible, maintain the product information in its proper catalog source and use the catalog inside the flow.

This makes product management much easier.

What happens when a product changes?

For example:

Product price changes from ₹999 to ₹1,099.

The correct place to maintain that product information is the catalog.

You shouldn't need to rebuild every flow that references the product simply because the product information changed.

Catalog is not the same as a flow

Remember:

Catalog

= product data.

Flow

= conversation logic.

Catalog component

= the point where your flow presents catalog content.

This separation is important.

Catalog is not the same as the AI

The AI decides how to converse.

The catalog contains structured product information.

They can work together, but they serve different purposes.

A useful architecture

Product Information
       ↓
Meta Catalog
       ↓
ZazzyAgent
       ↓
Flow Builder
       ↓
Customer

Once you understand that relationship, configuring catalogue-based automation becomes much easier.

That means there are now more places where something can go wrong.

Your Flow may be correct while the external API is returning an error.

Or the API may work while ZazzyAgent is mapping the response incorrectly.

The fastest way to troubleshoot is to identify exactly where the failure occurs.

The complete API path

Think of the workflow as:

Flow
 ↓
Request
 ↓
Authentication
 ↓
External API
 ↓
Response
 ↓
Response Mapping
 ↓
Next Flow Step

Check each layer separately.

Problem 1: API verification fails

If the API cannot be verified while setting it up, check:

• Endpoint

• HTTP method

• Authentication

• Request parameters

• Required headers

• Request body

The current API workflow validates the integration before saving it and reports errors when verification fails.

Problem 2: Authentication error

Common symptoms include:

401 Unauthorized

or:

403 Forbidden

Check your:

• API key

• Bearer token

• Authentication header

• Account permissions

• Credential status

Make sure the credential belongs to the correct external system.

Problem 3: Wrong HTTP method

Your external API may require:

POST

while your ZazzyAgent configuration uses:

GET

Check the external API documentation.

Problem 4: Missing parameter

Suppose the API requires:

order_id

but your request sends:

phone

The API can reject the request.

Check every required parameter.

Problem 5: Dynamic value isn't being sent

Your API may depend on customer information collected earlier.

For example:

Customer enters order number.

If that value isn't mapped into the API request, the API won't know which order to look up.

Check:

User Input

→ Saved Field

→ API Request

Problem 6: API returns an error

Your external system may return:

{
  "error": "Order not found"
}

Don't display the raw error to the customer.

Create a customer-friendly fallback.

For example:

I couldn't find that order number. Please check the number and try again.

Problem 7: API returns no data

The API may successfully respond but contain an empty result.

Example:

{
  "appointments": []
}

Your automation needs an appropriate path:

No appointments are available for that date. Please choose another date.

Problem 8: API response mapping fails

The API may return:

order_status

while your mapping expects:

status

The API worked.

The mapping did not.

Check the exact response structure.

Problem 9: Dynamic list is empty

If you're using an API-powered dynamic list, inspect the data at every step.

Check:

1. API returned data.

2. Data was captured.

3. Custom field contains the response.

4. JSON structure is correct.

5. List mapping matches the response.

6. List is connected to the active branch.

Problem 10: API works in testing but fails in the live flow

This usually indicates that the live request is different from your test request.

Check:

• Dynamic values

• Customer data

• Request parameters

• Authentication

• Headers

• URL variables

Problem 11: API takes too long

An external system may be slow.

Don't assume a fixed Delay solves an API timeout.

A Delay only waits.

It does not make a failed API request succeed.

The API itself needs to respond correctly within the available execution time.

Problem 12: API returns unexpected data

A third-party API may change its response structure.

For example:

Old:

status

New:

order_status

Your mapping can stop working even though the API endpoint still responds.

Check the current response whenever an integration suddenly stops working.

Problem 13: Wrong customer data is returned

Check which customer information is being used in the request.

For example, if the API request accidentally uses a static order number, every customer could receive the same result.

Dynamic values should come from the appropriate customer input or stored field.

Problem 14: API works but customer receives no reply

The API step may be successful while the next Flow node isn't connected correctly.

Check:

API

→ Response

→ Next message

Also verify conditions between those steps.

Problem 15: Don't expose technical errors

Avoid sending customers:

HTTP 500 Internal Server Error

Instead say:

We couldn't retrieve that information right now. Please try again or contact support.

Technical details belong in logs/debugging, not customer-facing replies.

Build a fallback path

A reliable API workflow should include a failure strategy.

For example:

API Call
   ↓
Successful?
 ↙       ↘
Yes       No
 ↓         ↓
Continue   Friendly
          Error Message

Test failure scenarios

Don't test only the happy path.

Test:

• Valid input

• Invalid input

• Missing input

• API error

• Empty response

• Expired authentication

• Wrong response structure

Use logs when available

When debugging a webhook/API workflow, inspect the relevant logs and payload information available in ZazzyAgent.

The current workflow documentation specifically recommends checking webhook logs for receipt, timestamps, payloads and failures.

A useful debugging order

Always work from left to right:

Did the Flow run?

↓

Was the API called?

↓

Was the request correct?

↓

Did the external system respond?

↓

Was the response correct?

↓

Was it mapped?

↓

Did the next Flow step run?

This prevents guessing.

The key rule

When an API-powered automation breaks:

Don't troubleshoot the whole flow at once.

Find the exact point where the data stopped moving.

That is usually where the problem is.

For example:

• Mumbai

• Delhi

• Pune

• Bengaluru

But what if the available options change constantly?

For example:

Available appointments today.

The answer might change every few minutes.

This is where a Dynamic List becomes useful.

What is a dynamic list?

A dynamic list creates interactive options using data provided by another source.

A common architecture is:

Customer
   ↓
HTTP API
   ↓
Fresh Data
   ↓
Dynamic List
   ↓
Customer selects an option

The current Flow Builder supports dynamic lists driven by external API data and mapped fields.

When should you use a dynamic list?

Use one when the choices change.

Examples:

• Available appointments

• Available products

• Delivery slots

• Service locations

• Agents

• Restaurants

• Hotel rooms

• Classes

• Courses

• Inventory

Example: Appointment availability

Customer:

I want to book today.

Your automation calls:

Appointment API

The API returns:

10:00 AM
1:00 PM
4:00 PM

ZazzyAgent generates the list.

The customer chooses:

1:00 PM

The workflow continues with that selection.

Step 1: Create the API

Create an HTTP API configuration that returns the information you need.

See How to Use HTTP API in ZazzyAgent Flow Builder.

Step 2: Store the response

Configure your workflow so the API response can be used by the dynamic list.

The current dynamic-list workflow uses structured response data stored in a custom field before mapping the list values.

Step 3: Prepare your data

Your API might return data like:

[
  {
    "name": "10:00 AM",
    "description": "Available",
    "id": "1000"
  },
  {
    "name": "1:00 PM",
    "description": "Available",
    "id": "1300"
  },
  {
    "name": "4:00 PM",
    "description": "Available",
    "id": "1600"
  }
]

Your list can use:

name

as the visible title.

description

as supporting text.

id

as an internal value.

Step 4: Configure the dynamic list

Open the appropriate list component in Flow Builder.

Configure the source data.

Map the fields returned by the API to the fields expected by the list.

Step 5: Set the visible title

Choose which API field the customer should see as the main option.

For example:

name

produces:

10:00 AM

Step 6: Add a description

If your data contains a description, use it to provide additional context.

Example:

10:00 AM

Available

or:

10:00 AM

Limited availability

Step 7: Map the selected value

The list should return enough information to identify what the customer selected.

For example:

1300

could represent the 1:00 PM slot.

You can then use that value in the next API call.

Example: Booking process

Customer
   ↓
Choose Date
   ↓
HTTP API
   ↓
Available Slots
   ↓
Dynamic List
   ↓
Customer selects 1:00 PM
   ↓
Booking API
   ↓
Confirmation

This is much better than manually creating a fixed list of appointment times.

Example: Product availability

Your API returns:

Product A
Product B
Product C

The customer sees:

Product A

Product B

Product C

The list updates whenever your underlying system changes.

Example: Delivery slots

The API returns today's available windows:

9 AM – 12 PM
12 PM – 3 PM
3 PM – 6 PM

The customer chooses one.

The next API call can attempt to reserve it.

Dynamic list vs normal list

Normal list

You define the options manually.

Best for:

• Fixed categories

• Permanent choices

• Small menus

Dynamic list

The options come from changing data.

Best for:

• Availability

• Inventory

• Real-time records

• Customer-specific results

Dynamic list vs carousel

Use:

Dynamic List

when the customer mainly needs to choose from text.

Use:

Carousel

when the customer needs to browse visual cards.

Dynamic list and customer-specific data

A particularly powerful use case is retrieving different options for different customers.

For example:

Show appointments for Rahul's assigned sales representative.

The API can return only the relevant results.

Then the dynamic list displays those options.

Dynamic list and conditions

You can also filter the result before displaying it.

For example:

Customer Type = Enterprise

→ Enterprise appointment options.

Customer Type = Standard

→ Standard appointment options.

Dynamic list and AI

AI can help determine what the customer wants.

For example:

Customer:

I want to book tomorrow afternoon.

AI identifies:

Date = Tomorrow

Time Preference = Afternoon

The automation then calls the availability API and displays the relevant dynamic list.

Common dynamic-list problems

List is empty

Check:

• API response

• Stored custom field

• JSON structure

• Mapping

Wrong titles appear

Check the title-field mapping.

Wrong option is selected

Check the ID/value mapping.

API returns data but list doesn't display it

Check whether the returned data is in the expected structure.

Options are outdated

Check when the API is being called.

The list is only as current as the source data being retrieved.

Test with realistic data

Don't test only with:

Option 1
Option 2

Use real API response structures.

Also test:

• Empty result

• One result

• Multiple results

• Unexpected value

• API failure

The architecture to remember

External System
      ↓
HTTP API
      ↓
Structured Response
      ↓
Custom Field / Mapping
      ↓
Dynamic List
      ↓
Customer Choice
      ↓
Next Action

This turns ZazzyAgent into an interface for your live business data.

Suppose your API returns:

{
  "name": "Rahul",
  "status": "Shipped",
  "tracking": "TRK12345"
}

ZazzyAgent needs to know which pieces of that response you want to use.

This is where Response Mapping becomes important.

What is response mapping?

Response mapping connects information returned by an API to fields that ZazzyAgent can use.

For example:

API response
    ↓
status
    ↓
Order Status

Then your automation can use the stored value later.

Our current API integration supports mapping returned response data into custom fields.

Why map API responses?

Mapped data can be used for:

• Customer messages

• Conditions

• Personalization

• Dynamic lists

• Subsequent automation

• Customer records

Example: Order API

API returns:

{
  "order_status": "Out for Delivery"
}

Map:

order_status

to:

Order Status

Then your flow can use the stored value.

Example: Customer API

API returns:

{
  "customer_name": "Rahul",
  "customer_type": "VIP"
}

You could map:

customer_name

→ Customer Name

customer_type

→ Customer Type

Then a condition could check:

Customer Type = VIP

Map only the fields you actually need

An API may return 30 pieces of information.

You may only need three.

For example:

• Status

• Tracking number

• Delivery date

Don't create unnecessary fields for every response property.

Custom fields are useful here

Suppose your API returns:

appointment_date

You can save it into:

Appointment Date

Then a later step can use that value.

Use response data in messages

Suppose the API returns:

status = Confirmed

Your next message could communicate the result to the customer.

The exact variable syntax depends on how the field is exposed within the relevant ZazzyAgent message component.

Use response data in conditions

This is one of the most useful patterns.

Example:

API
 ↓
Order Status
 ↓
Condition
 ↓
┌───────────────┐
Confirmed       Pending
 ↓                 ↓
Confirmation      Wait message

Use response data in dynamic lists

An API can return multiple records.

For example:

[
  {
    "name": "10:00 AM",
    "id": "1000"
  },
  {
    "name": "2:00 PM",
    "id": "1400"
  }
]

Those values can be turned into interactive options in supported dynamic-list workflows.

API response data and customer profiles

Mapping information into customer fields means the data can become part of the customer record.

For example:

Last Order Status

Shipped

Now the information isn't only used for the current reply.

It can remain available for later automation where appropriate.

Handle missing values

Suppose your API normally returns:

tracking_number

but some orders haven't shipped yet.

Your automation needs to account for that.

Don't assume the field will always contain a value.

You can use conditions to determine which path should run.

Handle unexpected responses

An API may sometimes return:

error

or:

null

Build your automation to handle these situations.

Don't save everything permanently

Not every API response belongs in the customer's profile.

Ask:

Will this information be useful later?

If no, it may only need to exist for the current flow.

If yes, consider mapping it into a custom field.

Example: Lead scoring

Your CRM API returns:

lead_score = 87

Map:

87

→ Lead Score

Then:

Lead Score > 80
        ↓
High Intent

You can then:

• Add a label

• Notify sales

• Assign a human

• Trigger another flow

Example: Inventory

API returns:

stock = 4

Condition:

Stock > 0

→ Available

Otherwise:

→ Out of Stock

The customer gets current information rather than a manually maintained message.

Test mapped values

Always verify that:

• API returned the expected property.

• Mapping points to the correct field.

• The field receives the expected value.

• The next step uses the correct field.

Common mistakes

Wrong response property

The API may return:

order_status

while you mapped:

status

Check the actual response.

Nested data

Your API may return information inside nested objects.

Understand the response structure before mapping.

Missing field

Don't assume every response contains every value.

Wrong field type

A date, number and text may behave differently when used in conditions.

The complete pattern

Customer Input
      ↓
HTTP API
      ↓
API Response
      ↓
Response Mapping
      ↓
Custom/System Data
      ↓
Condition / Message / Dynamic List
      ↓
Customer

This is the basic architecture behind many real-time ZazzyAgent integrations.

It can also communicate with external systems using an HTTP API.

For example, a customer asks:

Can you check my order?

Instead of replying with a fixed message, your automation can call your order system, receive the current information and use the result in the conversation.

That's the basic purpose of HTTP API integration.

What is an HTTP API?

An API allows one system to communicate with another system.

In a ZazzyAgent flow, the basic architecture can look like:

Customer
   ↓
ZazzyAgent Flow
   ↓
HTTP API
   ↓
External System
   ↓
API Response
   ↓
ZazzyAgent
   ↓
Customer

What can you use an API for?

Common examples include:

• Checking order status

• Looking up customer information

• Checking appointment availability

• Retrieving product information

• Sending lead data to a CRM

• Creating a support ticket

• Checking account status

• Retrieving prices

• Connecting custom business software

The current API integration supports HTTP methods including GET, POST, PUT and DELETE, along with response mapping back into subscriber/customer fields.

When should you use an API?

Use an API when ZazzyAgent needs information or an operation that belongs to another system.

For example:

"What is my order status?"

The information belongs to your ecommerce system.

ZazzyAgent should retrieve it rather than maintain a separate manually updated copy.

Example: Order lookup

Customer:

Order 12345 status?

Your flow can:

1. Capture the order number.

2. Call the order API.

3. Send the order number to the external system.

4. Receive the response.

5. Map the response.

6. Reply to the customer.

Example response:

Your order #12345 is out for delivery.

Example: Appointment availability

Customer:

Can I book tomorrow?

Your automation can call:

Booking API

and retrieve available slots.

For example:

API Response

10:00 AM
1:00 PM
4:30 PM

The available options can then be presented to the customer.

Create an HTTP API integration

Open the HTTP API/integration area in ZazzyAgent.

Create a new API configuration.

Give it a meaningful name.

For example:

Check Appointment Availability

rather than:

API 1

Choose the HTTP method

Depending on what your external system expects, choose the appropriate method:

GET

Usually used to retrieve data.

POST

Usually used to send information or create something.

PUT

Usually used to update information.

DELETE

Used to delete information where your external system supports that operation.

The API must be configured according to the requirements of the external service.

Enter the endpoint

Provide the API endpoint.

For example:

https://api.example.com/orders

Use the actual endpoint supplied by your system.

Add authentication

Your API may require authentication.

Examples include:

• API key

• Bearer token

• Other supported authentication methods

Store credentials using the secure configuration available in ZazzyAgent rather than putting secrets into customer-facing messages.

Add request parameters

Suppose your endpoint expects:

order_id
12345

Your Flow can pass the customer's captured order number as the request value.

This lets the same API configuration work for different customers.

Use dynamic customer data

API requests become much more useful when the request can use information collected earlier in the flow.

Example:

User Input
   ↓
Save Order Number
   ↓
HTTP API
   ↓
Use Order Number

Now each customer can retrieve their own information.

Example: Lead submission

Suppose a website or chatbot collects:

• Name

• Email

• Phone

• Requirement

An HTTP API can send this information to your CRM.

The flow becomes:

Customer
   ↓
User Input
   ↓
Save Fields
   ↓
HTTP API
   ↓
CRM

Read the API response

Calling the API is only half the process.

You also need to understand the response.

For example:

{
  "status": "shipped",
  "tracking_number": "TRK12345"
}

You might want to use:

status

and:

tracking_number

in the next step of your flow.

Response Mapping

Response mapping lets you map returned API data into the appropriate customer/subscriber fields.

Our current API functionality supports syncing returned response data into subscriber fields through response mapping.

For example:

API status
    ↓
Order Status custom field

Show API data to the customer

Suppose your API returns:

name = Rahul
status = Shipped
date = September 10

Your next message can use the mapped information.

For example:

Hi Rahul. Your order is shipped and is expected on September 10.

Use an API in a condition

You can combine API results with Flow Builder conditions.

For example:

API
 ↓
Appointment Available?
 ↓
YES → Show booking options
NO  → Ask customer to choose another date

This creates genuinely dynamic automation.

API errors

Your workflow needs to account for failures.

Possible problems include:

• Invalid API URL

• Authentication failure

• Timeout

• Invalid request

• External server error

• Unexpected response

• Missing data

Don't build a workflow that assumes every API call will succeed.

Test the API before using it in a flow

The current API integration workflow verifies the API configuration before allowing the integration to be saved.

Test:

• Request

• Authentication

• Parameters

• Response

• Response fields

before connecting it to a customer-facing flow.

API and Flow Builder

A typical API-powered automation looks like:

Trigger
   ↓
Collect Input
   ↓
HTTP API
   ↓
Response
   ↓
Condition
   ↓
Customer Reply

This is one of the most powerful patterns available in Flow Builder.

API vs Webhook

These are related but different.

HTTP API

ZazzyAgent actively calls another system.

Webhook

Another system sends information to ZazzyAgent.

Think:

API = ZazzyAgent asks.

Webhook = another system tells ZazzyAgent.

See What Is a Webhook in ZazzyAgent?.

API vs Google Sheets

Google Sheets can be useful for simple structured data.

An API is usually better when you need real-time communication with another application.

For example:

Simple internal data

→ Google Sheets

Live booking system

→ API

API security

Never expose private API credentials in:

• Customer messages

• Public URLs

• System Prompt text intended for customers

• Flow messages

Use the secure API configuration available in the platform.

Best practices

Keep APIs focused.

For example:

Check Order Status

is better than an undocumented endpoint that does ten unrelated things.

Make the expected request and response structure clear.

Also design a fallback response for errors.

A complete example

Customer:

I want to know my appointment availability.

Flow:

Ask date

↓

Save date

↓

Call HTTP API

↓

API returns:

10:00
13:00
16:30

↓

Show available options

↓

Customer selects one

↓

Continue booking.

That's the difference between a static chatbot and an automation connected to live business data.

For example:

Hi!

Welcome to our business.

What would you like to do?

Choose an option.

All four messages arriving instantly can feel like a machine dumping text into the customer's chat.

A Delay can create a more natural sequence.

What is Delay?

A Delay tells ZazzyAgent to wait before continuing to the next step in a flow.

For example:

Message
  ↓
Wait 3 seconds
  ↓
Next Message

The current WhatsApp flow troubleshooting documentation also identifies Delay as a flow element whose placement and timing can affect when subsequent messages are sent.

Why use Delay?

Delay can be useful for:

• Creating natural pacing

• Separating multiple messages

• Waiting before a follow-up

• Preventing messages from appearing all at once

• Creating short pauses before an action

Example: Welcome sequence

Instead of:

Message 1
Message 2
Message 3

use:

Message 1
   ↓
Delay
   ↓
Message 2
   ↓
Delay
   ↓
Message 3

The conversation feels more like a person or well-designed assistant communicating step by step.

How to add a Delay

Open the relevant flow in Flow Builder.

Add a Delay element between the two steps where you want the pause.

Configure the amount of time.

Then connect the Delay to the next step.

Choose sensible timing

The correct delay depends on what you're trying to accomplish.

For example:

1–3 seconds

can make a short message sequence feel less abrupt.

A longer delay may be appropriate when the automation is intentionally waiting for something.

Don't add delays randomly.

Don't fake human typing excessively

A small pause can improve readability.

But adding:

15 seconds

20 seconds

30 seconds

between ordinary messages simply to pretend a human is typing can frustrate customers.

The purpose is better pacing, not deception.

Use Delay between related messages

Example:

Thanks for your enquiry.

Delay

Let me show you our available options.

Delay

Which one are you interested in?

This is easier to read than three simultaneous messages.

Delay before a follow-up

Suppose a customer starts a booking process.

You may want:

Please complete the form.

Then later:

Need help completing it?

A delay can create that pause where appropriate.

Delay before launching a Flow

In some workflows, you may want a short pause before another structured experience begins.

For example:

"Great! Let's get your details."
       ↓
Delay
       ↓
WhatsApp Flow

This can make the transition feel cleaner.

Delay and external APIs

Be careful when an API is involved.

A delay does not automatically mean:

Wait until the API finishes.

An API operation and a Delay are different things.

If your workflow depends on an API response, make sure your API step and response handling are configured correctly rather than assuming a fixed delay will always be enough.

Delay and Webhooks

The same principle applies to webhook workflows.

Don't use:

Wait 5 seconds.

as a substitute for knowing whether an external process actually completed.

Use delays for timing.

Use API/webhook logic for system events.

Delay and broadcasts

Be careful with timing when sending messages to many customers.

Large automation systems can have additional sending, rate and platform constraints.

A delay inside a customer journey should not be treated as a universal solution to messaging limits.

Where should the Delay go?

Consider:

Correct:
Message
  ↓
Delay
  ↓
Next Message

The Delay must be in the actual branch being executed.

If you place it on another branch, it won't affect the path you're testing.

This is a common source of confusion when a flow appears to ignore a delay.

Example: Product presentation

Welcome
   ↓
Delay 2 sec
   ↓
Product Introduction
   ↓
Delay 2 sec
   ↓
Product Options

Example: Support flow

Customer chooses Support
       ↓
"Sure, I'll help."
       ↓
Delay
       ↓
"Please choose your issue:"
       ↓
Buttons

The short pause separates acknowledgement from the next instruction.

Example: Lead qualification

Customer submits details
       ↓
Delay
       ↓
"Thanks, we've received your information."
       ↓
Next step

When not to use Delay

Don't add delays:

• Everywhere

• Between every single message

• To hide slow integrations

• To compensate for broken logic

• To imitate human behaviour excessively

If your customer needs information immediately, give it immediately.

Delay troubleshooting

Delay has no effect

Check whether the Delay is actually connected to the path being tested.

Message appears too quickly

Check the configured duration.

Flow seems stuck

Make sure the Delay is not configured for an unexpectedly long period and that the next node is connected.

Only one branch has a delay

Remember that each branch has its own path.

A delay in one branch won't affect another.

Good automation pacing

A useful rule is:

Use delays where they improve comprehension, not simply because you can.

The customer should feel that the conversation has a natural rhythm without being made to wait unnecessarily.

You may want the customer to:

• Open your website

• Book an appointment

• View a product page

• Complete a form

• Make a payment

• Read documentation

• Visit a landing page

A CTA URL Button gives the customer a clear button that opens an external URL.

The current Flow Builder supports CTA URL buttons for WhatsApp chatbot and supported live-chat workflows.

What is a CTA URL button?

CTA means:

Call to Action

A CTA URL button is a clickable action that takes the customer to a web address.

Example:

Ready to book your appointment?

Book Now

The button opens:

your booking page

When should you use a CTA URL?

Use it when the customer needs to leave WhatsApp for a specific reason.

Examples:

Book Appointment

→ Booking website

View Product

→ Product page

Make Payment

→ Payment page

Read Guide

→ Documentation

Apply Now

→ Application form

Create a CTA URL message

Open Flow Builder.

Create or edit your WhatsApp flow.

Select the CTA URL Button message type.

The current setup uses the CTA URL Button message option inside the bot flow editor.

Add the message content

Write a short body message.

Example:

You can choose your appointment time on our booking page.

Then add the CTA button:

Book Appointment

Enter the URL

Add the destination URL.

Make sure it is the exact page you want customers to visit.

Good:

Your booking page

Poor:

Homepage

when the customer actually needs to book an appointment.

Send customers to the right page

A common mistake is sending everyone to the homepage.

Instead, use a deep link where possible.

For example:

Product enquiry

→ Specific product page

Booking request

→ Booking page

Support question

→ Support portal

CTA for lead generation

Example:

Want to request a quote?

Request Quote

→ Landing page with the quote form.

This can complement your ZazzyAgent lead-generation automation.

CTA for bookings

Example:

Choose a convenient time for your appointment.

Book Appointment

→ Online booking system.

CTA for payments

Example:

Your payment link is ready.

Make Payment

→ Secure payment page.

Only send customers to a payment URL you trust and control.

CTA for product pages

Example:

Here's the product you asked about.

View Product

→ Product URL.

This is particularly useful after an AI Agent answers a product question.

CTA vs WhatsApp Flow

Use CTA URL when the next step belongs on your website.

Use a WhatsApp Flow when you want the customer to complete a structured form inside WhatsApp.

For example:

WhatsApp Flow

Collect name, email and requirement.

CTA URL

Customer needs a full booking interface.

CTA vs button that starts a flow

A flow button keeps the customer inside the automated conversation.

A CTA URL takes the customer to another destination.

Choose based on what you want the customer to do next.

Use clear button labels

Good:

Book Appointment

View Product

Get Directions

Complete Application

Poor:

Click

The customer should understand the destination.

Add context before the CTA

Don't send:

[Click Here]

Instead:

You can see all available appointment slots here.

View Availability

The customer knows what will happen.

Track the customer's journey

When someone clicks your CTA, they leave the ZazzyAgent conversation for the external website.

Where your website supports it, use appropriate analytics or tracking so you can understand what happens after the click.

Don't send broken URLs

Before enabling your automation, open the link yourself.

Check:

• Correct URL

• Page loads

• Mobile experience

• HTTPS

• Relevant content

• No login problems unless intended

Test from a phone

A URL that works on a desktop should also be tested on a mobile device.

WhatsApp customers are usually interacting from their phones.

Common problems

Button doesn't appear

Check that the CTA URL message is configured correctly.

Button opens wrong page

Check the exact URL.

Website doesn't load

Test the destination URL independently.

Customer doesn't know why they should click

Rewrite the message and button text.

Example: Lead generation

Interested in a Demo?
        ↓
CTA URL
"Book Your Demo"
        ↓
Website Booking Page

Example: Product enquiry

Customer asks about Product A
        ↓
AI / Bot
        ↓
Product information
        ↓
"View Product"
        ↓
Product page

The rule to remember

Use a CTA URL when:

The customer's next action is better completed on your website than inside WhatsApp.

You may want to show:

• Several products

• Different service packages

• Multiple offers

• Different properties

• Several plans

Instead of sending separate messages one after another, you can use a Carousel.

A carousel presents multiple cards that customers can browse through.

The current Flow Builder supports WhatsApp Carousel Templates for bot flows and other supported messaging workflows.

What is a Carousel?

A carousel is a horizontally browsable collection of cards.

Each card can contain information such as:

• Image

• Title

• Description

• Button/action

For example:

[ Product A ] [ Product B ] [ Product C ]
    image         image         image
   Details       Details       Details

The customer can browse the cards and choose the one they're interested in.

When should you use a Carousel?

Use a carousel when customers need to compare several visual options.

Great examples include:

Products

Show multiple products.

Services

Show different packages.

Properties

Show several properties for sale or rent.

Plans

Show different subscription or service plans.

Offers

Show current promotions.

Create a Carousel

Open your WhatsApp Flow Builder.

Create or open the flow where you want the carousel.

Select the Carousel Template component.

Add your first card

Start with the most important option.

Add:

Image

Title

Description

Action/button

Example:

Premium Plan

Advanced automation for growing businesses.

Learn More

Add more cards

Continue adding the options you want customers to browse.

For example:

Starter

Growth

Enterprise

Each card should represent a meaningful choice.

Make every card consistent

Use a similar structure for all cards.

For example:

Card 1
Image
Title
Description
Button

Card 2
Image
Title
Description
Button

Card 3
Image
Title
Description
Button

Don't make one card extremely detailed and another almost empty.

Consistency makes the carousel easier to scan.

Use strong images

Carousel messages are highly visual.

Use images that:

• Clearly show the product/service

• Have similar dimensions

• Are good quality

• Don't contain excessive text

For products, actual product images are generally better than generic graphics.

Write short descriptions

Don't turn each card into a full product page.

Example:

Premium WhatsApp automation with AI, shared inbox and advanced workflows.

is better than several paragraphs inside the card.

The purpose is to get the customer to choose.

Add a clear button

Good:

View Details

Get Quote

Buy Now

Book Demo

Poor:

Click Here

Connect each card

A carousel becomes useful when its actions lead somewhere.

For example:

Card: Starter
       ↓
Starter Details

Card: Growth
       ↓
Growth Details

Card: Enterprise
       ↓
Talk to Sales

Carousel for product discovery

A customer asks:

Show me your products.

Your automation can respond with:

Product A

Product B

Product C

The customer chooses one.

Then the corresponding product flow starts.

Carousel for services

A service business could show:

Consultation

Installation

Maintenance

Each card can lead to:

More information

or:

Book Now

Carousel and AI

An AI Agent can be used before or after the carousel.

Example:

Customer:

I'm looking for a plan for a small business.

AI:

I can show you some options.

↓

Carousel:

Starter

Growth

Business

The customer can then choose.

Carousel and lead qualification

A carousel can be the beginning of a sales journey.

Example:

Service A

→ Request Quote

→ Lead Qualification

Service B

→ Request Quote

→ Lead Qualification

This creates a visual entry point into a structured sales process.

Carousel vs interactive list

Use a Carousel when the options are visual.

Use a List when the customer mainly needs to choose from text.

Example:

Carousel

Products with images.

List

Cities:

• Mumbai

• Pune

• Delhi

• Bengaluru

Carousel vs separate messages

Sending:

Product A

then:

Product B

then:

Product C

creates a long conversation.

A carousel keeps the choices together.

Don't put everything into one carousel

If you have 30 products, displaying everything in one carousel may not be useful.

Instead:

Product Categories

↓

Customer chooses category

↓

Show relevant carousel.

Example: Real estate

Customer:

Show me available properties.

Your bot can display:

2BHK Andheri

3BHK Bandra

2BHK Powai

Each card could have:

View Property

The next step can show details or open a website.

Example: Restaurant

Customer:

Show me your special dishes.

Carousel:

Pizza

Burger

Pasta

Each card can show an image and description.

Test each card

This is important.

Test:

• First card

• Middle card

• Last card

• Every button

• Every destination

Make sure customers don't accidentally enter the wrong flow.

Common problems

Carousel doesn't appear

Check whether the carousel is configured for the correct WhatsApp account and message workflow.

Card image doesn't appear

Check the media configuration.

Button opens the wrong flow

Check the action connected to that card.

Carousel is too long

Reduce the number of cards or introduce categories.

Best carousel structure

Question
   ↓
Carousel
   ↓
Visual Options
   ↓
Customer selects
   ↓
Relevant Flow

A carousel is most useful when the customer needs to browse before deciding.