Pre-Call Data Fetch

Pre-Call Data Fetch lets you enrich the call context and select model settings before the voice agent starts. Configure it on the Start Call node for every call, inbound calls only, or outbound calls only. Returned variables are merged into the call’s initial context and become available in prompts and greetings.

How It Works

Voice AiLunaPro resolves and saves the call’s model setup from the organization default, the workflow override, and the API-trigger override, checks billing and quota, and connects the call.
As soon as the call is connected, AiLunaPro sends a POST request to your endpoint. The caller hears a ringer while the request is in flight. For outbound calls this happens after the callee answers.
Your API returns context variables, model overrides, or both.
AiLunaPro merges the context, applies any model overrides to the agent’s LLM, LLM fallback, and TTS, and validates the result.
The agent starts and plays its greeting.

Configuration

Open the Start Call node editor and expand Advanced Settings. Choose a Pre-Call Data Fetch mode and configure the endpoint when the mode is not disabled:

Field	Description
Pre-Call Data Fetch	Disabled, Always, Inbound calls only, or Outbound calls only. Calls without an inbound or outbound direction run the fetch only in Always mode.
Endpoint URL	The URL AiLunaPro will send the POST request to.
Authentication	Optional credential for authenticating the request. Supports API key, bearer token, basic auth, and custom header.

Request Format

AiLunaPro sends a POST request with the following JSON payload:

{
  "event": "call_inbound",
  "call_inbound": {
    "agent_id": 123,
    "workflow_run_id": 456,
    "from_number": "+12137771234",
    "to_number": "+12137771235"
  }
}

Field	Description
`event`	Always `"call_inbound"`.
`call_inbound.agent_id`	The workflow (agent) ID.
`call_inbound.workflow_run_id`	The run ID of this call.
`call_inbound.from_number`	The caller’s phone number (`caller_number` from initial context).
`call_inbound.to_number`	The called phone number (`called_number` from initial context).

The Content-Type header is application/json. If you configured a credential, its authentication header is included. Caller and callee numbers are supplied when known at the time the call connects. The request includes an Idempotency-Key header such as dograh-pre-call-456. AiLunaPro sends the request once per call. Make your endpoint idempotent using this key if it performs writes or other side effects.

Expected Response Format

Your API should return a JSON object with a 2xx status code. The variables to inject into the call context should be placed inside the initial_context key:

{
  "call_inbound": {
    "initial_context": {
      "customer_name": "Jane Doe",
      "account_status": "active",
      "loyalty_tier": "gold",
      "open_tickets": 2
    }
  }
}

You can also place initial_context at the top level:

{
  "initial_context": {
    "customer_name": "Jane Doe",
    "account_status": "active"
  }
}

The legacy dynamic_variables key is still accepted as a drop-in alias for initial_context, so existing integrations keep working without any changes. Use initial_context for new integrations. If a response contains both keys, initial_context takes precedence.

After the response is received, you can reference these values anywhere template variables are supported:

Greeting: Hello {{customer_name}}, thank you for calling!
Prompt: The customer is a {{loyalty_tier}} member with {{open_tickets}} open support tickets.

If the response is not a valid JSON object, or the request fails or times out, the call continues using its earlier context and model settings. A response without context fields leaves context unchanged. Invalid or unsupported model_overrides are logged and ignored; the call continues on its already-selected models.

Override models for this call

Return model_overrides beside initial_context, either at the top level or inside call_inbound:

{
  "call_inbound": {
    "initial_context": {
      "customer_name": "Jane Doe"
    },
    "model_overrides": {
      "llm": {
        "settings": {
          "temperature": 0.2
        }
      },
      "tts": {
        "settings": {
          "voice": "default"
        }
      }
    }
  }
}

Use a voice supported by the selected TTS provider. You may return only model_overrides when no context enrichment is needed. If you use the call_inbound envelope, put both fields inside it. Fetched model settings take precedence over workflow and API-trigger settings for the services the agent owns: llm, llm_fallback, and tts. A service may also select a provider_connection_uuid, following the same-provider and different-provider rules of API trigger overrides, as long as it keeps the AiLunaPro service key the call was authorized with. The call is already connected when your endpoint answers, so the hook cannot change what the call pipeline was built with: it cannot select a named configuration (model_configuration_uuid) or change mode, stt, realtime, or embeddings. Set those on the workflow or the API trigger instead. Realtime (speech-to-speech) agents ignore model_overrides entirely. Overrides cannot change credentials, connection endpoints, organization identity, or billing metadata. Unknown or unsupported fields, missing or unrelated UUIDs, incompatible indexed-document embeddings, and incompatible service selections are rejected: the rejection is logged against the run and the call continues on its already-selected models. Settings are validated locally without testing credentials against model providers. The resolved settings are saved for this run and do not modify your named configurations.

Nested Variables

If your initial_context contains nested objects, you can access them using dot notation:

{
  "call_inbound": {
    "initial_context": {
      "customer": {
        "name": "Jane Doe",
        "address": {
          "city": "Los Angeles"
        }
      }
    }
  }
}

Access in prompts as {{customer.name}} and {{customer.address.city}}.

Timeout

The request has a 10-second timeout. If your API does not respond within this window, the call proceeds without the fetched data. Respond quickly to minimize the delay before dialing or starting the agent.

Testing with Test Calls

When a real phone call comes in, the caller_number and called_number context variables are automatically set by the telephony provider and included in the pre-call data fetch request as from_number and to_number. For web calls (WebRTC), there are no real caller and callee phone numbers, so provide test context if your endpoint requires them. Phone calls use the caller and callee information available when the call connects. To simulate telephony data during testing:

Open your workflow and go to Settings.
Under Context Variables, add the following variables:
- caller_number — set to a phone number you want to simulate as the caller (e.g., +12137771234).
- called_number — set to the number that would be dialed (e.g., +12137771235).
Save the settings.

Now when you make a web test call, these values will be sent in the pre-call data fetch request to your endpoint, allowing you to test the full flow as if a real inbound call were coming in.

Use actual telephony numbers when present. Test context is useful for WebRTC calls that have no telephony metadata.

Example Integration

A simple Node.js endpoint that looks up a customer by phone number:

app.post("/ailunapro/pre-call", async (req, res) => {
  const { call_inbound } = req.body;

  const customer = await db.customers.findOne({
    phone: call_inbound.from_number,
  });

  if (!customer) {
    return res.json({});
  }

  res.json({
    call_inbound: {
      initial_context: {
        customer_name: customer.name,
        account_status: customer.status,
        loyalty_tier: customer.tier,
      },
    },
  });
});

Getting started

Build your First Agent

Core Concepts

Configurations

Voice Agent Builder

Telephony

Integrations

How It Works

Configuration

Request Format

Expected Response Format

Override models for this call

Nested Variables

Timeout

Testing with Test Calls

Example Integration

​How It Works

​Configuration

​Request Format

​Expected Response Format

​Override models for this call

​Nested Variables

​Timeout

​Testing with Test Calls

​Example Integration

How It Works

Configuration

Request Format

Expected Response Format

Override models for this call

Nested Variables

Timeout

Testing with Test Calls

Example Integration