OTLP endpoints reference

Every path into Osuite ends at the same place: OTLP arriving at your region’s ingest endpoint over TLS. This page is the reference for those endpoints — regions, protocols, the authentication header, and the exact format each kind of client expects. For how telemetry flows end to end, see Architecture.

Regions

Osuite runs in independent regions. Your data lives in the region where your account was created, and each ingest endpoint is region-specific — telemetry is never routed between regions.

Region	Ingest endpoint
US	`ingest.us.osuite.io:443`
India	Not yet finalised — use the `ingest.<region>.osuite.io:443` placeholder

The India region’s exact hostname slug is not yet confirmed. Keep <region> in copy-paste config so the same snippet works once the India slug is published; in prose, the US host is ingest.us.osuite.io.

Osuite also exposes a per-region query API at https://api.<region>.osuite.io, used by the CLI and AI agents and authenticated with an API key. That is a separate endpoint from the OTLP ingest endpoint described here.

Protocols and ports

OTLP is carried two ways, and Osuite’s ingest endpoint accepts both on port 443:

gRPC — a single connection multiplexes all three signals. This is the default transport for most OpenTelemetry SDKs and Collectors.
HTTP/protobuf — each signal is sent to a path under the endpoint (/v1/traces, /v1/logs, /v1/metrics). OpenTelemetry SDKs append these paths automatically.

The OpenTelemetry defaults are port 4317 for gRPC and 4318 for HTTP/protobuf, but Osuite’s managed ingest endpoint terminates both on 443. Always send to ingest.<region>.osuite.io:443 regardless of protocol.

Authentication

Authenticate every request with your ingest token in the x-osuite-ingest-token header.

x-osuite-ingest-token: <your-ingest-token>

OpenTelemetry SDKs set this through OTEL_EXPORTER_OTLP_HEADERS; Collectors set it under the exporter’s headers: block. The ingest token is distinct from the API key the CLI uses — the token authorises telemetry ingest, the key authorises querying.

TLS

The ingest endpoint requires TLS. Because it listens on 443, standard clients negotiate TLS by default and no extra flags are needed — do not disable transport security (for example, do not set OTEL_EXPORTER_OTLP_INSECURE=true or a Collector exporter’s tls.insecure: true).

Endpoint format

Write the endpoint the same way everywhere:

https://ingest.<region>.osuite.io:443

OpenTelemetry SDK environment variables:
Terminal window
```
OTEL_EXPORTER_OTLP_ENDPOINT="https://ingest.<region>.osuite.io:443"
```
Over gRPC this value works for OTEL_EXPORTER_OTLP_ENDPOINT and the per-signal variants alike. Over HTTP/protobuf the two behave differently: the SDK appends /v1/traces, /v1/logs, or /v1/metrics to OTEL_EXPORTER_OTLP_ENDPOINT, but sends a per-signal variant exactly as written. A per-signal variant must therefore carry the full path:
Terminal window
```
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://ingest.<region>.osuite.io:443/v1/traces"
```
Osuite’s HTTP ingest only accepts paths under /v1/, so a per-signal variant left as a bare host posts to / and is rejected. Setting the single OTEL_EXPORTER_OTLP_ENDPOINT avoids this entirely — prefer it unless you need to split signals across endpoints.

OpenTelemetry Collector exporters use the same value under endpoint::

exporters:
  otlp/osuite:
    endpoint: "https://ingest.<region>.osuite.io:443"
    tls:
      insecure: false
    headers:
      x-osuite-ingest-token: <your-ingest-token>

Some gRPC clients also accept a bare ingest.<region>.osuite.io:443 — the Python SDK’s gRPC exporter does, for example. The https:// form works in every client, so prefer it and you never have to think about which is which.