Regions & Endpoints

Regional endpoint URLs for all Nozomi APIs.

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 →

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

Base URLs

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 decides priority regardless of method.

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.

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. If your workload genuinely cannot hold a connection open, consider the QUIC Client.

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. If you need more throughput, request a higher rate limit (see FAQ → 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.