# 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:

```text
order_id = 12345
```

A customer API may need:

```text
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:

```text
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:

```text
/orders?order_id=12345
```

uses a URL query parameter.

Another API may expect:

```json
{
  "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:

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

For example:

```text
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:

```text
order_id
```

The customer enters:

```text
12345
```

The API request uses that value.

The next step can then use the returned status.

For example:

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

## Use parameters for search

Parameters are also useful for retrieving specific records.

For example:

```text
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:

```text
date = 2026-09-25
service = consultation
```

Your flow can collect:

```text
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:

```text
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:

```text
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](https://blog.zazzyagent.com/validate-user-input-zazzyagent).

## Common parameter problems

### Parameter is empty

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

Check:

```text
User Input
   ↓
Saved Field
   ↓
API Parameter
```

### Wrong parameter name

The API may require:

```text
order_id
```

while the request sends:

```text
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:

```text
2026-09-25
```

but your workflow sends:

```text
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:

```text
country = IN
```

### Dynamic

Changes based on the conversation.

Example:

```text
order_id = customer's order number
```

Dynamic parameters are particularly useful for customer-specific APIs.

## Multiple parameters

An API can require several values.

Example:

```text
customer_id
order_id
store_id
```

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

A typical structure is:

```text
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:

```text
Endpoint
Method
Headers
Parameters
Body
```

Then compare it with the external API requirements.

For example:

```text
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](https://blog.zazzyagent.com/api-errors-zazzyagent-flow-builder).

## Testing dynamic parameters

Test at least three cases:

### Valid value

```text
12345
```

### Invalid value

```text
ABC123
```

### Missing value

```text
(empty)
```

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

## The reusable API pattern

```text
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](https://blog.zazzyagent.com/http-api-zazzyagent-guide).

## 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.