How to Search the Web with Exa AI in a Jinba Workflow

Summary

• Exa AI Search returns structured JSON fields (results[].title, url, text, highlights) and offers four latency profiles from ~250 ms to 4–15 s; use auto or deep for compliance research.
• Jinba Flow's API node can call Exa directly, and a condition node routes results deterministically — the same input always produces the same auditable path.
• The audit trail records the full Exa request, response, condition evaluated, branch taken, timestamps, and invoker — answering "why did the agent do X?"
• Exa's top-level compliance parameter filters at the data source, while Jinba records evidence that the filter was applied.
• To implement, build a trigger → Exa API node → condition node workflow in Jinba Flow, then publish it as a governed MCP tool.

AI agents operating on static training data have a well-known ceiling. They cannot answer questions about what happened last week, what a regulator published this quarter, or what a competitor announced this month. That is a capability gap. The harder problem is governance: when an agent does retrieve information and acts on it, most platforms give operators no reliable way to answer "why did the agent do X?"

Fragmented toolchains make this worse. Each resource carries its own RBAC configuration and its own logging format, which means audit evidence is scattered across systems rather than consolidated in one place.

This guide shows how to close both gaps. Using Jinba Flow's API node, you can call the Exa AI Search API from inside a deterministic workflow, route the structured results through a condition node, and record every action in a single, centralized audit trail. The result is a governed, repeatable process for real-time web intelligence.

What each component does

Exa AI is an API-first search platform built for AI agents. It returns structured JSON, supports domain filtering, compliance scoping, and exposes four documented latency profiles so operators can match speed to cost. It is not a wrapper around a general-purpose search engine; it is designed to produce machine-readable output that downstream nodes can act on directly.

Jinba Flow is the workflow builder inside the Jinba platform. It publishes AI-powered processes as APIs or batch jobs, enforces routing rules through condition nodes, and captures a full execution record for every run. Jinba is documented as three products: Jinba Flow, Jinba App, and Jinba Toolbox.

The exa ai integration here is direct: Jinba's API node calls Exa's REST endpoint, receives structured results, and feeds them into the rest of the workflow. No intermediary layer is required.

Prerequisites

Before building the workflow, confirm the following:

• An active Exa AI account with an API key. The Exa onboarding dashboard at dashboard.exa.ai/onboarding generates ready-to-run code snippets for testing the key before it enters a workflow.
• Access to a Jinba Flow environment, for example at flow.jinba.io.

Step 1: Create and trigger the workflow

Open Jinba Flow and create a new workflow. Add a trigger node as the entry point. The trigger can be an inbound API call, a scheduled event, or a manual execution. The choice depends on how the workflow will be invoked: on-demand by another system, on a recurring schedule, or interactively during development.

Step 2: Configure the Exa search node

Add an API node immediately after the trigger. This node makes the outbound call to Exa.

Configure the node with the following values:

• Method: POST
• Endpoint: https://api.exa.ai/search
• Headers:
• • Content-Type: application/json
  • x-api-key: YOUR_EXA_API_KEY
• Body:

{
"query": "What are the latest PCI-DSS 4.0 compliance requirements?",
"numResults": 5,
"type": "auto",
"contents": {
"text": true,
"highlights": {
"num_sentences": 2,
"highlights_per_url": 1
}
}
}

The contents object is the key to downstream routing. When text is true and highlights is configured, each result in the response carries results[].title, results[].url, results[].text, and results[].highlights as addressable fields. The condition node in the next step reads directly from these fields.

Step 3: Choose the right search type for your use case

Exa's Search API Guide documents four latency profiles for the type parameter. Selecting the right one avoids paying for depth when speed is sufficient.

For compliance monitoring or regulatory research, auto or deep are appropriate because result quality matters more than response time. For pipelines that run on every user interaction, instant or fast keeps latency manageable.

Domain filtering further tightens result quality. The includeDomains and excludeDomains parameters restrict results to authoritative sources, and startPublishedDate / endPublishedDate remove content published outside a relevant window.

Step 4: Route structured results with a condition node

Add a condition node after the API node. The condition evaluates fields from Exa's JSON response and branches the workflow accordingly.

A concrete example for a compliance use case:

IF response.body.results[0].highlights CONTAINS 'HIPAA'
THEN route to 'Compliance Review' step
ELSE route to 'Standard Output' step

This logic is deterministic. The workflow takes the same path every time the same condition is true, which means the routing decision is reproducible and auditable. A human reviewer can inspect the condition, the input that triggered it, and the path taken, all from the audit log.

Results can also be routed by source domain, publication date, or the presence of named entities in the text field. The structure of Exa's response makes all of these fields available as addressable values without additional parsing.

Governance in action: the audit log

Jinba captures every workflow execution in a governance audit trail. According to Jinba's enterprise documentation, every call made through Jinba is recorded with the invoking user or system, input data, execution steps, and output.

For an Exa search workflow, that record includes:

• The invoking user or system identity
• The full Exa API request body, including the query string and any compliance parameter
• The API key reference used for the call
• The complete Exa response, including all results[] fields
• The condition evaluated and the branch taken
• Timestamps for each execution step
• The downstream path and its output

This answers the governance question directly. When operators need to explain why an agent retrieved a particular set of results and why it routed them to a specific downstream step, the audit log contains the complete, time-stamped record. Jinba's enterprise workflow governance documentation specifies that the audit trail records full execution history with timestamps, approver IDs, and decisions.

Enforcing compliance at the data source

Before results enter the workflow at all, Exa's top-level compliance parameter scopes the search to a specific regulatory regime.

{
"query": "Best practices for storing patient health information",
"numResults": 3,
"compliance": "hipaa"
}

Setting compliance to "hipaa" instructs Exa to return only results consistent with that regulatory context. This is a pre-filter, applied at the data source before any result reaches Jinba. The condition node and audit log then verify and record that the enforcement happened.

The two controls work in sequence: Exa's compliance parameter enforces the policy at retrieval, and Jinba's audit log provides the immutable record that it was enforced. Neither control substitutes for the other.

Publish the workflow as a reusable MCP tool

Once the workflow is tested and stable, Jinba Flow can publish it directly as an MCP server endpoint. The entire governed search process becomes a single callable tool.

Other AI agents or teams call this tool without managing Exa API keys, configuring condition nodes, or maintaining routing logic. They inherit the compliance scoping, the audit trail, and the routing rules automatically. A "Governed Web Search" tool built once in Jinba Flow is available to every authorized agent in the organization.

This is distinct from connecting directly to Exa's hosted MCP server at https://mcp.exa.ai/mcp, which exposes Exa's raw search, code search, and agent tools without the workflow layer. Publishing through Jinba wraps those capabilities in the organization's own governance controls before exposing them downstream.

What to build next

The workflow pattern described here applies beyond compliance queries. Any process that requires current, sourced information and a verifiable record of how that information was retrieved and acted on follows the same structure: trigger, Exa API call with appropriate type and compliance parameters, condition-based routing, audit-log capture.

Start with a single, narrow query, confirm the audit record meets the organization's requirements, then extend the workflow to cover additional domains or routing branches. The audit log is the mechanism that turns an AI action from an opaque event into an accountable, reviewable decision.

For teams operating under sector-specific requirements such as HIPAA or PCI-DSS, the combination of Exa's compliance scoping and Jinba's centralized audit trail provides the documentation layer that fragmented, per-resource logging cannot.

Frequently Asked Questions

What is Jinba Flow?

Jinba Flow is the workflow builder inside the Jinba platform that publishes AI-powered processes as APIs or batch jobs. It enforces routing rules through condition nodes and captures a full execution record for every run. In the context of this article, Jinba Flow provides the deterministic environment where an Exa AI search becomes an auditable, governed step rather than an unrecorded call.

How do I connect Exa AI to Jinba Flow?

Connect Exa AI to Jinba Flow by adding an API node after the workflow trigger. Configure the node with the POST method, the https://api.exa.ai/search endpoint, the Content-Type and x-api-key headers, and a JSON body containing the Exa query parameters. The API node makes the outbound call and returns Exa's structured response directly to the next node, so no intermediary service is required.

What does the Exa AI Search API return?

The Exa AI Search API returns structured JSON results that include fields such as results[].title, results[].url, results[].text, and results[].highlights. When you set contents.text to true and configure highlights, each result carries addressable text and highlight fields. This structure allows downstream nodes, such as Jinba Flow's condition node, to route decisions without additional parsing.

Why should I route Exa AI results through a condition node?

Routing Exa AI results through a condition node makes the workflow deterministic and auditable. The same condition produces the same branch every time, so operators can inspect the rule, the input that triggered it, and the path taken. This is essential for compliance use cases where you need to prove why particular search results were sent to a specific downstream process.

What compliance controls are available when using Exa AI with Jinba Flow?

Two main compliance controls work together. Exa's top-level compliance parameter scopes the search to a regulatory regime, such as "hipaa", before results enter the workflow. Jinba Flow then records the full execution in an immutable audit trail, including the request body that contained the compliance parameter. Together they provide both enforcement and evidence.

How does Jinba Flow create an audit trail for web searches?

Jinba Flow records every workflow execution with the invoking user or system, input data, execution steps, and output. For an Exa search workflow, the audit trail includes the full Exa API request, the API key reference, the complete response, the condition evaluated, the branch taken, and timestamps for each step. This centralized record answers the governance question “why did the agent do X?” without searching across separate systems.

Can I publish a governed Exa search workflow as an MCP server?

Yes. Once the workflow is tested, Jinba Flow can publish it directly as an MCP server endpoint. Other agents and teams then call the governed search process as a single tool, inheriting the compliance scoping, routing rules, and audit trail automatically. This is different from connecting directly to Exa's hosted MCP server, which exposes raw search tools without the organization's workflow-level governance layer.

Which Exa search type should I use for compliance monitoring?

For compliance monitoring or regulatory research, use the auto or deep search type. auto balances latency and depth for general-purpose search, while deep is appropriate for comprehensive research where speed is less critical. Use instant or fast for high-frequency, cost-sensitive pipelines where moderate result depth is acceptable.

How do domain and date filters improve Exa search results?

Exa's includeDomains and excludeDomains parameters restrict results to authoritative sources, helping you avoid low-quality or irrelevant domains. The startPublishedDate and endPublishedDate parameters remove content published outside a relevant window. These filters tighten result quality before the condition node evaluates the response, which improves both accuracy and auditability.