> For the complete documentation index, see [llms.txt](https://use.temporal.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://use.temporal.xyz/nozomi/endpoints.md).

# Regions & Endpoints

## Authentication

All requests require your API key passed as a query parameter:

```
?c=<YOUR_API_KEY>
```

Don't have an API key yet? Create one in the dashboard. [**Sign up →**](https://dashboard.nozomi.temporal.xyz/sign-up?utm_source=docs\&utm_medium=cta\&utm_campaign=nozomi_access\&utm_content=endpoints)

There is **no IP whitelisting**. Access is controlled entirely by the API key. A `401` response always means the key is missing or invalid, never that your IP is blocked.

## API Paths

| Method     | Path                    | Response              |
| ---------- | ----------------------- | --------------------- |
| JSON-RPC   | `/`                     | Transaction signature |
| API v2     | `/api/sendTransaction2` | Empty body, `200 OK`  |
| Batch Send | `/api/sendBatch`        | Empty body, `200 OK`  |

## Base URLs

| Type        | URL                        | Notes                    |
| ----------- | -------------------------- | ------------------------ |
| Auto-routed | `nozomi.temporal.xyz`      | Via Cloudflare proxy     |
| Geo-DNS     | `edge.nozomi.temporal.xyz` | Routes to nearest region |

Auto-routed is recommended for most users. It will always route your request to the closest regional server.

**Example:** `https://nozomi.temporal.xyz/api/sendTransaction2?c=<YOUR_API_KEY>`

## Choosing a Submission Method

Nozomi offers several ways to submit. They differ in overhead, not in queue priority: your [tip](/nozomi/tipping-and-faq.md) decides priority regardless of method.

| Method                                                 | Overhead   | Returns signature? | Notes                                                                                                     |
| ------------------------------------------------------ | ---------- | ------------------ | --------------------------------------------------------------------------------------------------------- |
| [Batch Send](/nozomi/batch-send.md)                    | **Lowest** | No                 | Compact binary; **fastest path even for a single transaction**.                                           |
| [API v2](/nozomi/transaction-submission-api-v2.md)     | Low        | No                 | Plain-text base64 body, no JSON parsing.                                                                  |
| [JSON-RPC](/nozomi/transaction-submission-json-rpc.md) | Higher     | Yes                | Drop-in Solana RPC replacement; use when you need the signature back.                                     |
| [QUIC Client](/nozomi/transaction-submission-quic.md)  | n/a        | No                 | Only for workloads that cannot hold a persistent connection open. Not faster than a warm HTTP connection. |

For the absolute lowest latency, use **Batch Send** over a **direct `http://` endpoint** on a **warm, reused connection** (see Best Practices below).

## Regional Endpoints

Pin to a specific datacenter for lowest latency if you are co-located. Each region is available as a direct connection or through Cloudflare.

Direct endpoints support both `http://` and `https://`. Cloudflare endpoints support `https://` only.

| Region      | Direct                     | Cloudflare                |
| ----------- | -------------------------- | ------------------------- |
| Pittsburgh  | `pit1.nozomi.temporal.xyz` | `pit.nozomi.temporal.xyz` |
| Newark      | `ewr1.nozomi.temporal.xyz` | `ewr.nozomi.temporal.xyz` |
| Ashburn     | `ash1.nozomi.temporal.xyz` | `ash.nozomi.temporal.xyz` |
| Los Angeles | `lax1.nozomi.temporal.xyz` | `lax.nozomi.temporal.xyz` |
| Frankfurt   | `fra2.nozomi.temporal.xyz` | `fra.nozomi.temporal.xyz` |
| Amsterdam   | `ams1.nozomi.temporal.xyz` | `ams.nozomi.temporal.xyz` |
| London      | `lon1.nozomi.temporal.xyz` | `lon.nozomi.temporal.xyz` |
| Tokyo       | `tyo1.nozomi.temporal.xyz` | `tyo.nozomi.temporal.xyz` |
| Singapore   | `sgp1.nozomi.temporal.xyz` | `sgp.nozomi.temporal.xyz` |

All servers run custom hardware modifications.

## Direct vs Cloudflare

**Direct** endpoints connect straight to the Nozomi server with no intermediary. This gives the lowest possible latency for servers and co-located infrastructure. Direct endpoints also let you connect over plain `http://`, which is the fastest option, because `https://` (TLS) has to encrypt every transaction you send, adding latency to each request. Use `http://` for lowest latency; use `https://` only when you need encryption in transit.

**Cloudflare** endpoints route through Cloudflare's network before reaching Nozomi. Residential ISPs often have better backbone connectivity to Cloudflare's edge than to individual datacenters, which can make proxied endpoints faster for users on home or mobile connections. Cloudflare also handles TLS termination at the edge, reducing handshake latency.

Use **direct** if you are running from a datacenter or VPS with good peering. Use **Cloudflare** if you are on a residential connection, have variable network quality, or are building a browser-based application.

## Best Practices

#### Lowest latency

For latency-critical workloads:

* **Use Batch Send over a direct `http://` endpoint.** Plain HTTP avoids per-transaction TLS encryption; batch avoids JSON and per-request overhead.
* **Co-locate near your target region and pin to it.** Latency introduced before your request reaches Nozomi (your client → the region) can decide races that Nozomi cannot fix downstream.
* **Keep one warm connection open and reuse it.** Establishing a new connection per transaction pays the handshake cost every time. See [TCP Keep-Alive](/nozomi/keeping-your-tcp-connection-alive.md). If your workload genuinely cannot hold a connection open, consider the [QUIC Client](/nozomi/transaction-submission-quic.md).

#### Send to multiple regions

For the highest landing probability, send the same transaction to **multiple regional endpoints simultaneously**. Rate limits are applied per region, so sending the same transaction to multiple regions will not count against your rate limit. It effectively multiplies your throughput and adds redundancy.

Nozomi also cross-forwards internally between regional servers, so the **Regions** view in the dashboard reflects where your transactions *landed*, not the endpoints you submitted to.

#### One key, not many

Use a **single API key** and send each transaction **once per key** (per region). Splitting traffic across multiple keys, or rotating keys with a delay, does **not** improve landing. It raises your failure/spam rate and can hurt your [priority](/nozomi/faq.md#priority). If you need more throughput, request a higher rate limit (see [FAQ → Rate Limits](/nozomi/faq.md#rate-limits)).

#### Frontend clients

If you are integrating Nozomi into a browser-based application:

* Send each transaction to **both a direct and a Cloudflare endpoint** at the same time. Network conditions vary across users: some will be faster through Cloudflare, others through a direct connection. Sending to both ensures the fastest path wins.
* Use **API v2** or **Batch Send** with `Content-Type: text/plain` or `application/octet-stream` to skip the CORS preflight `OPTIONS` request. Standard JSON-RPC with `Content-Type: application/json` triggers a preflight that adds 50–100ms of latency.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://use.temporal.xyz/nozomi/endpoints.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.