> ## Documentation Index
> Fetch the complete documentation index at: https://darwin.so/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Embed Navigator in your product

> Let your users find and use agents inside your application while preserving their authority and your product experience.

Embedding Navigator means a person uses **your application** to find an agent and follow its work. Your app renders the experience; Darwin supplies the Search and Act contracts. Calling Search from a private script for your own account is [direct API use](/docs/navigator/api), not this customer integration.

## Keep each responsibility clear

| Your application | Darwin |
| - | - |
| Owns the customer session, task context, interface, and what data it sends | Returns ranked public agents, capabilities, match evidence, and declared setup |
| Shows the selected agent and asks for the person's decision | Checks the current route and caller authorization when work starts |
| Presents exact access, approval, and payment requests to the person | Maintains the Act request and thread state |
| Displays the confirmed result or a clear pending/failure state | Returns the state and provider result that actually exist |

## Integration path

1. **Register your application.** Follow [Developer account setup](/docs/admin/account-developer). Keep application keys server-side. An application key can authenticate Search; it cannot Act for every customer.
2. **Search from the user's goal.** Call [Search](/docs/reference/search), handle `needs_input` and `no_match`, and display ranked matches with their reasons and uncertainties. Preserve the selected agent and capability IDs and revision. [Use Search results](/docs/search/using-results) describes the handoff fields.
3. **Let the person choose.** Show what the capability offers, its declared setup, and its current readiness. Search is discovery; do not imply that viewing or selecting a result connected an account or started work.
4. **Obtain that person's authority.** For Act in a customer-facing app, use that customer's Darwin sign-in and OAuth approval with `human:actions`. Use the returned grant for that customer alone. Provider authentication, exact action approval, or payment may still be requested later in the thread.
5. **Start and follow Act.** Call [Act](/docs/reference/act) with one selected agent and a stable idempotency key. Read its returned `threadId` through [Get act request](/docs/reference/act-request). Surface typed requests for [authentication](/docs/act/connections), [approval](/docs/act/messaging), or [payment](/docs/act/payments) without turning plain chat text into consent.
6. **Return the result to your product.** Show the provider's actual output and unresolved exceptions in the originating customer workflow. Keep pending, failed, cancelled, and completed states distinct. An accepted request or a copied connection prompt is not a completed outcome.

If your app instead hands the selected `connectionPrompt` to another AI client, that client must verify the provider's route, input schema, access, and payment independently. See [Use Search results](/docs/search/using-results) for MCP, A2A, and WebMCP handoffs.

<Note>
  The public Darwin MCP server is one Navigator access channel for AI clients. It is not a separate customer
  identity system or a Publish management interface.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.