From an invitation link to a first response through Gatekeeper. Six steps, every command run against the production router.
TutorialFor users, developers
By the end you have an account, an API key, a Gatekeeper that admits the production router, and one request that went through it. Nothing here is a mock-up: the terminal output is from a real run against api.router.superprotocol.com on Linux, so the file paths in it are Linux paths.
You need a shell, curl, and an invitation link. Registration on the production deployment is by invitation.
1. Create an account
Open the invitation link you were sent. The landing page reads the code from the link and carries it to the console. Click Start with your $100 credit.
The console opens Create an account. Type a name (optional) and your email address, then click Email me a code. The console mails a 6-digit code to that address; type it under Enter your code and click Create account. There is no password: the code is the proof that the mailbox is yours.
You land on Credits, where the balance already includes the invitation's grant as a row named Invitation credit.
2. Create an API key
Open API Keys and click New key. In the New API key dialog give the key a name, leave the model scope unrestricted, and click Create key.
The Copy your key now dialog shows the key exactly once. It starts with sk-tee-v1-. Copy it into your environment:
sh
exportSUPERPROTOCOL_API_KEY=sk-tee-v1-...
Closing the dialog loses the key for good: the router stores only a hash. If that happens, revoke the key and create another. The fields a key can carry are on API keys.
3. Install Gatekeeper
Gatekeeper is a single static binary for macOS, Linux and Windows. The script detects your OS and CPU, downloads the matching archive from the latest release, verifies it against the release checksums, and installs one binary and nothing else.
output on this machine, 2026-10-12
$ curl-fsSLhttps://github.com/Super-Protocol/confidential-router/releases/latest/download/install.sh | shInstalling gatekeeper 0.3.0 (linux/amd64) from gatekeeper-v0.3.0Checksum OKInstalled /home/you/.local/bin/gatekeepergatekeeper 0.3.0 (commit f23d2d6ef30c27785028b6dfc7f3d2f9a86a60a5, built 2026-10-09T11:19:08Z, go1.26.0, linux/amd64)
The script installs into /usr/local/bin when that is writable and ~/.local/bin otherwise, and tells you if the directory is not on your PATH. Other options are on Install Gatekeeper.
On macOS and Linux, add the install directory to the terminal you are in before the next step:
shfrom the console
exportPATH="$HOME/.local/bin:$PATH"
The installer runs in a child process and cannot change the PATH of the shell that called it, so without this line the next command is not found on any shell that does not already search that directory, a stock macOS zsh among them. Terminals you open afterwards are fine: the installer has already arranged that. Windows needs no equivalent, because iex runs the script in your own session.
4. Point Gatekeeper at the router
Four commands. They are the ones the console prints under API Keys → How to connect, with the production API origin already filled in.
The third command fetches the router's published evidence, runs every check, and prints the report before it asks you to confirm. This is what it printed against production:
$ gatekeeperendpointtrustaddrouter--from-upstreamDENIED — verified, but policy: the built-in pin policy (gatekeeper.default) deniedEndpoint routerUpstream https://api.router.superprotocol.comChecked just nowEvidence kind DeploymentEvidenceIssued 6s agoTrusted root attested:5690b13a922698ece1e9b64512910b58f1d60e338ff1d9e16f26cf631cdf409a (sha256:611bfbb75fa0adceb86128072e557c7defb5457e12d87173d57a3ea7d84ccefe) — attested (registry), not from trustedRootsObserved TLS leaf sha256:ce86d54e9e7275ce4132d7798d5fb18467dbe9a436178199f8441d240a8ef8ebSigned certFingerprint sha256:ce86d54e9e7275ce4132d7798d5fb18467dbe9a436178199f8441d240a8ef8ebevidenceDigest sha256:402198e23bc1bcd505a34d6cb28accd98f400e5444b0ca3a2d1e09d45ab72fc1Pinned for this endpoint noRoot certificate TEE evidence Verdict attested (registry) — this is a Super Swarm root Evidence type Intel TDX (Azure) Report integrity ok Chain revocation not checked Debug mode disabled Ciphertext hiding disabled Page swap disabled disabled Network type trusted Measurement 5690b13a922698ece1e9b64512910b58f1d60e338ff1d9e16f26cf631cdf409a (in trusted registry) Key binding 0e9652758883907a520eb516b9bb26276f7495c4ba95b1d1cde3e63009d90fef (matches the report data)Certificate chain (leaf → root) ROLE SUBJECT FINGERPRINT EXPIRES leaf CN=Super Swarm Evidence Subroot CA Level 1,OU=IT,O=SuperProtocol,L=New York,ST=NY,C=US sha256:e79e0c6f…e7b79d 2027-01-09 root CN=Super Swarm Root CA,OU=IT,O=SuperProtocol,L=New York,ST=NY,C=US sha256:611bfbb7…4ccefe 2036-10-08Container images docker.io/library/busybox@sha256:5cec3fc171c87218698e85a52af7087de727372aae264a787b8112901a5b0092 docker.io/library/haproxy@sha256:56b887da77428b7a6621e59e480cdbd330cc805c22d3cedb66ceea76ffdea2c6 ghcr.io/super-protocol/confidential-router/gatekeeper@sha256:56158ed17a2f7f9124d30215472ea0fe2ac3dc56974eb0e6808ba0aced11e7d8 ghcr.io/super-protocol/confidential-router/router-api@sha256:3e1600b0b820bf0a048582c2f8e403a06e991873e38348c8278508416b346954 ghcr.io/super-protocol/confidential-router/router-ui@sha256:fdd529f1751de8dcdc10821a54cff328e8d88915d6523c1ff3dc39359056a503 ghcr.io/zalando/spilo-17@sha256:b7db9e8f62e809ebd9a0679fbdba147a811fdd240ab78380ea4720a46a017184 quay.io/coreos/etcd@sha256:2c029095680c13c2b36116cc3935e1b0cddc0f5af78004457fd863616d8d072bPolicies POLICY PACKAGE RESULT (built-in) gatekeeper.default DENYPinned sha256:402198e23bc1bcd505a34d6cb28accd98f400e5444b0ca3a2d1e09d45ab72fc1 for "router" in /home/you/.config/confidential-gatekeeper/config.yaml
Read it before you answer. DENIED at the top is expected on a first run: every cryptographic check passed (the hardware report, the registry signature on the measurement, the chain, the TLS binding), and the only thing missing was a pin. The last line is your pin being written. The evidence digest you pinned is the one line to compare with what the console's Overview shows for this deployment.
Then run it:
shfrom the console
gatekeeperrun
With a terminal, run opens a dashboard. In a script or a container add --headless. From now on, Gatekeeper verifies before it forwards, re-attests every 5 minutes, and refuses the request if any check fails.
5. Send a request through it
Point your client at http://127.0.0.1:8787/v1 instead of the router. Take a model id from Models in the console; the deployment publishes the ids it serves.
The response is an OpenAI chat.completion object. Its usage carries three extra fields: cost_micros (what the request cost, in micro-dollars), endpoint (which router endpoint served it) and evidence_digest (the digest the platform had published for that endpoint at generation time). Every response also carries the header X-Gatekeeper-Verdict: allow, which is Gatekeeper's own statement that the checks passed on this connection.
A request that reaches the router with a missing or wrong key answers with a 401. This is the exact body the production router returned through a running Gatekeeper on this machine, with no key:
through the gatekeeper, no key
$ curl-sihttp://127.0.0.1:8787/v1/modelsHTTP/1.1 401 UnauthorizedContent-Type: application/json; charset=utf-8X-Gatekeeper-Verdict: allow{"error":{"message":"Incorrect API key provided. Send it as \"Authorization: Bearer sk-tee-v1-…\".","type":"authentication_error","code":"invalid_api_key"}}
The verdict header says Gatekeeper admitted the connection; the 401 is the router asking for your key.
6. See it in the console
Open Logs. The request is one row: time, model, which key, input and output tokens, cost, speed, time to first token, status. There is no prompt column, because the router never stores prompt or completion text.
Where next
Connect a client: the same base-URL swap in Python, Node, VS Code and OpenCode.