How to Use API Parameters in ZazzyAgent HTTP API Requests

An API often needs additional values before it can perform an operation.

These values are called parameters.

For example, an order API may need:

order_id = 12345

A customer API may need:

phone = +919999999999

The important part is that these values can come from the current customer rather than being manually entered for every request.

Why parameters matter

Without parameters, an API request may return generic information.

With parameters, the same integration can respond differently for each customer.

For example:

Customer A
Order 12345
       ↓
API
       ↓
Order 12345 status

Customer B
Order 98765
       ↓
API
       ↓
Order 98765 status

One API configuration can serve both customers.

Parameters vs request body

Parameters can be passed in different ways depending on the API.

For example:

/orders?order_id=12345

uses a URL query parameter.

Another API may expect:

{
  "order_id": "12345"
}

inside the request body.

These are not automatically interchangeable.

Follow the API documentation for the service you are connecting.

Use customer data dynamically

A common ZazzyAgent pattern is:

Customer Input
      ↓
Save Value
      ↓
HTTP API
      ↓
Use Saved Value as Parameter
      ↓
External System

For example:

Customer:
"My order number is 12345"

↓

Save order number

↓

Call Order API with:

order_id = 12345

↓

Receive order status

Example: Order lookup

Suppose your endpoint expects:

order_id

The customer enters:

12345

The API request uses that value.

The next step can then use the returned status.

For example:

Customer
   ↓
Order Number
   ↓
HTTP API
   ↓
Order Status
   ↓
Customer Reply

Use parameters for search

Parameters are also useful for retrieving specific records.

For example:

product_id
customer_id
appointment_id
ticket_id
order_id

Instead of creating one API integration for every record, use a dynamic value.

That turns a static integration into a reusable one.

Example: Appointment availability

Your external system may expect:

date = 2026-09-25
service = consultation

Your flow can collect:

Date
Service

and then send those values to the API.

The API can return the available appointments for that exact request.

Example: Customer lookup

Suppose a CRM API expects:

phone = +919999999999

The flow already knows the customer's phone number.

Use that value in the API request rather than asking the customer to provide it again.

Validate the parameter first

A parameter should contain the value the API expects.

For example:

Customer enters order number
        ↓
Is it present?
     ↙       ↘
   No         Yes
   ↓           ↓
Ask again    API request

You can use User Input and Conditions to validate values before making the API call.

See Validate User Input in ZazzyAgent.

Common parameter problems

Parameter is empty

The flow may not have saved the customer's input correctly.

Check:

User Input
   ↓
Saved Field
   ↓
API Parameter

Wrong parameter name

The API may require:

order_id

while the request sends:

order

Check the external API documentation.

Wrong value

Make sure the value being passed actually belongs to the customer making the request.

Incorrect format

An API may expect:

2026-09-25

but your workflow sends:

25/09/2026

Transform or validate the value before calling the API where necessary.

Static vs dynamic parameters

Static

Always uses the same value.

Example:

country = IN

Dynamic

Changes based on the conversation.

Example:

order_id = customer's order number

Dynamic parameters are particularly useful for customer-specific APIs.

Multiple parameters

An API can require several values.

Example:

customer_id
order_id
store_id

Your flow should collect or retrieve all required values before making the request.

A typical structure is:

Customer
   ↓
Collect Order Number
   ↓
Collect Store
   ↓
Save Data
   ↓
HTTP API
   ↓
Order System

Don't duplicate the same API integration unnecessarily

Suppose the same API is used for:

• Order status

• Delivery information

• Order history

Don't automatically create a separate integration simply because the customer value changes.

Instead, check whether the same endpoint and request structure can accept different parameters.

Keep each integration focused and clearly named.

Troubleshooting parameter errors

When the API returns an error, check the complete request:

Endpoint
Method
Headers
Parameters
Body

Then compare it with the external API requirements.

For example:

Expected:
order_id = 12345

Sent:
order_id = empty

The issue is not necessarily with the API itself.

The data may simply not have reached the request.

For broader API troubleshooting, see API Errors in ZazzyAgent Flow Builder.

Testing dynamic parameters

Test at least three cases:

Valid value

12345

Invalid value

ABC123

Missing value

(empty)

This helps confirm both your happy path and your fallback logic.

The reusable API pattern

Customer Input
      ↓
Store Value
      ↓
Validate
      ↓
HTTP API
      ↓
Parameter
      ↓
External System
      ↓
Response
      ↓
Customer

Once this pattern is understood, you can use the same approach for order lookups, booking systems, CRM searches, ticket systems, product databases, and custom business software.

For the complete API architecture, see HTTP API in ZazzyAgent: Complete Guide to External API Automation.

The key idea

An API integration becomes reusable when the request is built around dynamic data rather than hard-coded customer information.

Collect the value, validate it, pass it as the required parameter, and use the API response in the next step of your automation.