Introduction: If you store contact or case data in Airtable, you can use a webhook to look up information during a conversation. The flow collects an input (like a name or ID), sends it to your webhook endpoint, then uses the JSON response to personalize messages or route the contact automatically.
Run an Airtable lookup via webhook (then route automatically)
If you just need the essentials, follow this quick path:
- Confirm your webhook endpoint can query Airtable and return JSON
- Collect the lookup input (name / PID) and save it as a result
- Call the webhook (POST) and store the response
- Use returned keys in messages (test one key first)
- Split on the returned status (always keep an Other fallback)
- Handle Failed exits cleanly (user message + internal alert)
- Test in the simulator and verify JSON keys in the action log
This pattern keeps your flow fast, personalized, and easy to debug when data or endpoints change.
Step-by-Step Process
Before building the flow, make sure you have a webhook URL that:
- Accepts a POST request
- Receives JSON payloads
- Returns a JSON response with the fields your flow needs (example:
pid,status,full_name)
[CAPTURE: A simple diagram or documentation snippet showing “Flow → Webhook URL → Airtable → JSON response”.]
- Add a Send Message node asking for the input you will use to search Airtable (example: “Please reply with your full name” or “Enter your PID”).
- Add a Wait for Response node.
- Save the response with a clear result name (example:
lookup_input).
[CAPTURE: Send Message → Wait for Response saving “lookup_input”.]
- Add a new node and choose Call Webhook.
- Set the request method to POST.
- Paste your webhook URL (the service that queries Airtable).
- Name the webhook result (example:
airtable_lookup). - Save.
[CAPTURE: Call Webhook settings showing POST, URL field, and result name “airtable_lookup”.]
@contact and @results) as JSON to your webhook. If your service returns JSON, you can access it in the flow via the @webhook variable prefix.
Example JSON response from your webhook:
{
"pid": "P-10293",
"status": "active",
"full_name": "Jane Doe"
}You can reference values in the next nodes using the webhook JSON path, for example:
@webhook.json.pid@webhook.json.status@webhook.json.full_name
[CAPTURE: Send Message node showing “Thanks @webhook.json.full_name — your PID is @webhook.json.pid”.]
pid) to confirm your endpoint is returning what you expect.
- Add a Split by Expression node after the webhook.
- Evaluate a returned key (example:
@webhook.json.status). - Create categories for expected outcomes (example:
active,pending,not_found). - Send different messages or actions per category.
[CAPTURE: Split by Expression evaluating webhook status with categories and an “Other” fallback.]
The webhook action should provide Success and Failed exits.
- Connect Failed to an internal alert (email/notification/label) if available.
- Send the contact a helpful message (example: “We can’t retrieve your information right now. Please try again later.”).
[CAPTURE: Webhook node showing Success → normal flow, Failed → internal alert + user message.]
- Open the flow editor simulator (phone icon).
- Submit a test input (a name/ID that exists in Airtable).
- Check the simulator action log to confirm:
- The webhook request fired
- The JSON response returned
- Verify that your next steps (messages/splits) behave correctly.
[CAPTURE: Simulator view showing the action log with the webhook response JSON.]
Common Issues & Quick Fixes
My lookup always returns “not_found”
Problem: Valid contacts exist in Airtable, but your flow always routes to the not found path.
Fix: Confirm the webhook is searching the correct Airtable base/table/field and that you’re sending the expected input value. Use webhook events/logs to compare the incoming payload and the query your service performs.
Returned JSON keys don’t match what my flow expects
Problem: You reference @webhook.json.full_name but the response uses a different key (like name).
Fix: Standardize the response schema in your webhook service (recommended) or update the flow to reference the exact key names returned. Verify the final response in the simulator action log.
My response gets truncated
Problem: The stored webhook result is cut off and later routing becomes unreliable.
Fix: Return only the fields you need (pid/status/name). If you need more data, store it externally and return a reference ID for follow-up requests.