User Guide
Authentication & Access Keys
Every call to /api/* is authenticated with a single header. This page covers
what that key controls, how IP allowlisting works, and how BYOK changes the contract.
The access-key header
Send access-key: <your key> on every request. It does two jobs at once:
it identifies which owner you're acting as, and it's checked against that
key's IP allowlist. Get either wrong and you get a generic
401 Authentication failed, please confirm your details. — Airlock doesn't
distinguish "wrong key" from "right key, wrong IP" in the response, on purpose, so a caller
probing for valid keys learns nothing from the error message.
IP allowlisting
Each key can be locked to specific source IPs. When creating or managing a key you (or whoever administers your instance) set an allowed-IPs list:
| Value | Behavior |
|---|---|
0.0.0.0 | No IP restriction — the key works from anywhere |
192.168.1.100;10.0.0.50 | Semicolon-separated explicit list — only these IPs are accepted |
Airlock resolves "your IP" in this order: the cf-connecting-ip header (if you're
behind Cloudflare), then the first address in x-forwarded-for (if behind another
proxy/load balancer), then the raw socket address. If you're behind your own reverse proxy or
ALB, make sure it's setting one of those headers correctly, or your allowlisted IP will never match.
CIDR ranges aren't supported natively — allowlist explicit addresses, or put a firewall/proxy in front for range-based rules.
Bring Your Own Key (BYOK)
By default, secrets are encrypted with the service's own Fernet key. If you'd rather isolate
a secret with your own key, generate one and pass it as fernet-key on
every call for that secret — create, read, and update all need the same key:
python3 -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"Getting an access key
Dashboard logins aren't self-service — email contact@network14.cloud to request one. Once you're logged in, though, creating access keys is: create, edit the IP allowlist on, and revoke your own keys (up to 5 per account) directly from the dashboard. See Getting Started for what to expect when you're onboarded.
Key lifecycle & rotation
Keys don't expire on their own. Rotate periodically as a matter of hygiene, and immediately if a key may have leaked (for example, showing up unexpectedly in logs). To rotate, contact your Network14.cloud account team — they'll issue a new key and retire the old one.