# How to Use API Response Data in ZazzyAgent

Calling an API is only useful if you can do something with the information it returns.

Suppose your API returns:

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

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

```json
{
  "order_status": "Out for Delivery"
}
```

Map:

> `order_status`

to:

> `Order Status`

Then your flow can use the stored value.

## Example: Customer API

API returns:

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

You could map:

**customer\_name**

→ Customer Name

**customer\_type**

→ Customer Type

Then a condition could check:

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

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

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

## Use response data in dynamic lists

An API can return multiple records.

For example:

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

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

```text
error
```

or:

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

```text
lead_score = 87
```

Map:

**87**

→ **Lead Score**

Then:

```text
Lead Score > 80
        ↓
High Intent
```

You can then:

*   Add a label
    
*   Notify sales
    
*   Assign a human
    
*   Trigger another flow
    

## Example: Inventory

API returns:

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

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