> For a complete page index of the Captain API documentation, fetch https://docs.captain.dev/llms.txt?excludeSpec=true

# Edge Routing

> Requests to api.captain.dev connect at an edge location near the caller and travel a private backbone to Captain, reducing median query time by 16-39% in fresh-connection tests.

## Agent Quick Reference - Edge Routing

* **What changed**: `api.captain.dev` resolves to edge locations worldwide. TLS handshakes terminate near the caller; traffic reaches Captain over a private backbone.
* **Integration impact**: none. Same endpoint, same keys, same request format. No code change required.
* **Latency improvement**: 16-39% lower median query time in tests of 100 fresh-connection requests per city across seven cities.
* **Keep-alive note**: Connection reuse (HTTP keep-alive) already skips the handshake. Edge routing helps most when the caller opens a fresh connection for each request.

Requests to `api.captain.dev` now connect at an edge location near the caller and travel a private backbone to Captain. The public endpoint, authentication, and request format are unchanged: same endpoint, same keys, nothing to migrate.

## Why it matters

Global networking is part of taking a RAG pipeline from a local prototype to production. A search index can respond quickly while users far from the server still wait for connection setup. Measuring the full request from the caller's location makes that overhead visible.

A DIY RAG pipeline needs to account for connection reuse, routing, and the operational work of serving users across regions. Captain handles the edge connection and onward routing without requiring a separate search deployment in every caller's region. Edge Routing changes the network path; it does not replicate the search index to each edge location.

When an integration opens a fresh HTTPS connection for a query, connection setup adds network round trips. The TLS handshake on that connection used to cross the public internet end-to-end. With edge routing, the handshake terminates at the nearest edge location, and the request travels to Captain over a private backbone.

The improvement is largest for callers far from the origin region. Median Query Time on fresh connection · 100 samples / city:

| Calling from  | Before   | After  | Change |
| ------------- | -------- | ------ | ------ |
| São Paulo     | 805 ms   | 590 ms | −27%   |
| Singapore     | 1,136 ms | 692 ms | −39%   |
| Sydney        | 1,065 ms | 661 ms | −38%   |
| Dublin        | 687 ms   | 529 ms | −23%   |
| Frankfurt     | 738 ms   | 555 ms | −25%   |
| San Francisco | 641 ms   | 516 ms | −20%   |
| Portland      | 656 ms   | 551 ms | −16%   |

## When it does not help

Connection reuse (HTTP keep-alive) already skips the handshake. A long-lived client that reuses connections avoids repeated connection setup, so the fresh-connection results should not be applied to every query on that connection. The benefit depends on connection reuse and the caller's network path.

## Verifying the route

A query response includes a `cf-ray` header from the edge. Its suffix is the IATA airport code of the edge location that handled the connection (for example, `...SIN` for Singapore, `...GRU` for São Paulo). Seeing a code near the caller confirms the request was terminated at the edge.

```bash
curl -sI -X POST https://api.captain.dev/v3/collections/test/query \
  -H "Authorization: Bearer $CAPTAIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"test","limit":1}' 2>&1 | grep -i cf-ray
```

## Related

* [Query Latency](/guides/query-latency) for the full query processing waterfall.
* [Changelog: Edge Routing](/changelog/2026-09-10-edge-routing) for the original announcement.