Data connectors
How Clarify keeps user-built connectors safe — only real public endpoints, encrypted credentials, no redirects, and capped responses.

Data connectors let you point Clarify at your own systems using a URL you provide. Because you choose the address, Clarify treats every connector request as untrusted and runs it through a strict set of guardrails. This page explains, in plain terms, what those guardrails do — so you can connect your own services with confidence.

This page is specific to data connectors. For how Clarify protects everything else — logins, the relay, stored ticket data — see the Security overview.

Where your connector can reach

A connector can only reach real, public internet endpoints. Before every request, Clarify looks up the address behind your URL and checks it against a denylist. If the address is internal, private, or otherwise off-limits, the request is blocked before it ever leaves.

Blocked address types include:

Address typeExampleWhy it's blocked
Loopback127.0.0.1, localhostPoints back at the server itself
Private networks10.x, 172.16–31.x, 192.168.xInternal-only addresses
Cloud metadata169.254.169.254Would expose hosting credentials
Link-local & CGNAT169.254.x, 100.64.xInternal routing ranges
Multicast, reserved & test ranges—Never valid for a real API
If your connector needs to reach a service on your own network, put it behind a normal public domain with HTTPS first. Clarify can reach any genuine public endpoint.

No sneaky redirects

Some URLs try to bounce a request onward to a second address. A connector could, in theory, be pointed at a harmless-looking URL that redirects into an internal one.

Clarify never follows redirects on connector requests. It connects to the exact address it validated — nothing more. A redirect toward a private or internal host is stopped at the gate rather than quietly followed.

Response size cap

Every connector response is capped at roughly 1 MB (headers and body combined). This keeps a runaway or oversized response from overwhelming a ticket. If a response would exceed the cap, it's cut off rather than loaded in full. Connectors are designed for focused lookups — an order, a membership, a customer record — which comfortably fit within this limit.

Your credentials are protected

Whatever a connector needs to authenticate — an API key, a bearer token, a username and password, or OAuth credentials — is handled the same way as every other secret in Clarify.

Encrypted at rest
always on
Connector credentials are encrypted before they're stored, using strong, tamper-evident encryption. See Encryption for how this works across Clarify.
Never shown back to you
always on
Once saved, a credential is never displayed again — the dashboard only shows that a value is set, never the value itself. That's why editing a connector shows "leave blank to keep".
OAuth tokens minted server-side
always on
For connectors that use OAuth, the tokens are exchanged and encrypted on Clarify's servers. They never pass through your browser.
Give each connector only the access it needs. If your service offers a read-only API key, use that — a lookup connector never needs permission to change your data.

Optional extra layer

For teams that want defence in depth, Clarify supports an optional egress proxy — a separate, independent checkpoint that every connector request can be routed through. It re-runs the same address checks on its own, so even a mistake in one layer is caught by the other. This is a product-operated safeguard; there's nothing for you to configure.

The short version

Public only

Connectors reach genuine public endpoints — never internal, private, or cloud-metadata addresses.

No redirects

Requests are never bounced onward into a hidden internal host.

Size-capped

Responses are limited to about 1 MB, so nothing runs away.

Encrypted keys

Credentials are encrypted at rest and never shown back to you.

Want the full picture — logins, the relay, and what data is stored? Read the Security overview.