RelayKey docs

Building with Claude Code, Codex, or Cursor? See https://relaykey.ai/agents for the agent-targeted migration recipe.

RelayKey supports common API-key and bearer-token REST APIs. If your upstream API takes a header like Authorization: Bearer ... or x-api-key: ..., you can put it behind RelayKey today.

1. Sign in and create a connection — give it a name, the upstream base URL, and your real upstream API key.
2. Issue a delegated credential. Pick allowed methods, paths, and an expiration.
3. Hand the rk_proxy_... token (or the share link) to the vendor.
4. Watch each request appear in the audit log.

There are three places authentication shows up in RelayKey, each scoped to its own purpose.

Web dashboard

Magic-link sign-in by email. The dashboard sets an HTTP-only session cookie. No passwords.

Management API

Send a Bearer rk_mgmt_... token in the Authorization header on every request. Manage tokens at /app/settings.

Proxy / vendor calls

Vendors send the delegated credential token. Either header style is accepted — whichever the vendor SDK already uses:

Authorization: Bearer rk_proxy_...

x-api-key: rk_proxy_...

A connection holds the upstream base URL and your real upstream API key (encrypted at rest, decrypted only in memory at request time).

$ curl -X POST https://relaykey.ai/api/v1/connections \
    -H "Authorization: Bearer rk_mgmt_..." \
    -H "Content-Type: application/json" \
    -d '{
      "name":              "HubSpot — production",
      "base_url":          "https://api.hubapi.com",
      "auth_type":         "bearer",
      "upstream_key":      "pat-na1-...",
      "log_query_strings": false
    }'

For an x-api-key style API set auth_type: "header" and auth_header_name: "x-api-key".

A delegated credential is the token you hand to a vendor or agent. It is bound to a connection and has its own scope and expiration.

$ curl -X POST https://relaykey.ai/api/v1/delegated-credentials \
    -H "Authorization: Bearer rk_mgmt_..." \
    -H "Content-Type: application/json" \
    -d '{
      "connection_id":   "conn_a1b2c3",
      "name":            "Vendor X — read contacts only",
      "allowed_methods": ["GET"],
      "allowed_paths":   ["/crm/v3/objects/contacts/*"],
      "allowed_ips":     ["198.51.100.7/32"],
      "ttl_seconds":     86400
    }'

The response contains the raw rk_proxy_... token once. RelayKey stores only its SHA-256 hash. If you lose it, revoke and re-issue.

https://proxy.relaykey.ai/v1/<connection_id>/<upstream_path>

# Example
https://proxy.relaykey.ai/v1/conn_a1b2c3/crm/v3/objects/contacts?limit=10

RelayKey strips the /v1/<connection_id> prefix, joins the rest onto the connection's base_url, swaps in the upstream credential, and forwards the request. The credential's method and path are checked first; on mismatch the proxy returns 403 without making the upstream call.

The full schema lives in the OpenAPI spec on GitHub. The most common endpoints are listed here for quick reference.

See the full schema: docs/openapi.yaml.

Each delegated credential can carry a list of CIDRs. Ifallowed_ips is set and the request source IP is outside the list, the proxy returns 403 without making the upstream call. Available on all tiers.

"allowed_ips": ["198.51.100.7/32", "203.0.113.0/24"]

Does RelayKey ever see my upstream API key in plaintext?

Only in memory on the proxy server, just long enough to attach it to the outbound request. It is not logged and not echoed back in the dashboard after creation.

What happens when I revoke a credential?

The next request using that token returns 401 from RelayKey before any upstream call is made. Already-completed responses are not affected.

Can I bring my own domain?

On Agency. The proxy can be served from api.yourcompany.com via CNAME.

Where can I get help?

Email hello@relaykey.ai. Founder-assisted setup is available on every tier.