UniLink API Authentication (Bearer Tokens and API Keys)

Every UniLink API request must carry a Bearer token — here is how to generate one, attach it correctly, and keep it secure.

The UniLink API uses Bearer token authentication — a simple, widely supported scheme where you include a secret key in the HTTP header of every request. There are no cookies, no sessions, and no OAuth redirect flows for server-to-server integrations. You generate a key once in the dashboard, copy it into your application's configuration, and every authenticated request is one header away. Understanding the scope system and rotation workflow is what separates a secure integration from a fragile one.

What Bearer Token Authentication Does

Bearer tokens are long, randomly generated strings that act as both identity and credential in a single value. When you include Authorization: Bearer sk_live_abc123... in your HTTP request, the UniLink API verifies the token, identifies which account it belongs to, and checks whether its assigned scope permits the requested operation. If verification passes, the request proceeds. If the token is missing, invalid, or lacks the required scope, the API returns a 401 or 403 error immediately.

UniLink API keys support three scopes. A read scope key can call any GET endpoint but cannot create, update, or delete resources. A write scope key can call GET, POST, and PUT endpoints. An admin scope key additionally allows DELETE operations and access to account-level settings endpoints. You choose the scope when generating a key. A key's scope cannot be changed after creation — generate a new key if you need a different scope.

Keys do not expire automatically, but you should treat them like passwords. Rotate keys periodically, immediately after a team member with access leaves, and immediately if you suspect a key has been exposed in logs, source code, or error messages. Revocation is instant — go to Settings → API, find the key in the list, and click Revoke. Any request using a revoked key receives 401 within seconds.

How to Get Started

1. Log in to your UniLink dashboard at app.unilink.us and navigate to Settings → API in the sidebar.
2. Click Generate API Key. Enter a descriptive name for the key (for example, "Zapier — read contacts") and select the appropriate scope: read, write, or admin.
3. Copy the key from the modal immediately. UniLink shows the full key value only once. If you close the modal without copying, you must revoke the key and generate a new one.
4. Store the key in your application environment — use an environment variable such as UNILINK_API_KEY, a secrets manager like AWS Secrets Manager, or a .env file that is not committed to version control.
5. Verify the key works with a test request: curl -H "Authorization: Bearer YOUR_KEY" https://unilink.us/api/v1/pages. A 200 response confirms successful authentication.

How to Use the Authentication Header

1. curl: Add -H "Authorization: Bearer YOUR_KEY" to any curl command targeting the UniLink API.
2. JavaScript (fetch): Pass headers: { 'Authorization': 'Bearer ' + process.env.UNILINK_API_KEY } in your fetch options object.
3. JavaScript (axios): Set axios.defaults.headers.common['Authorization'] = 'Bearer ' + process.env.UNILINK_API_KEY once at startup to apply it to every request automatically.
4. Python (requests): Pass headers={'Authorization': f'Bearer {os.environ["UNILINK_API_KEY"]}'} to any requests.get() or requests.post() call.
5. Any other language: Set the Authorization HTTP header to the string Bearer followed immediately by your key — the space after "Bearer" is required by the HTTP specification.

Key Settings

Get the Most Out Of API Authentication

Create one API key per integration rather than sharing a single key across all your tools. This practice limits the blast radius if a key is compromised — you can revoke just the affected key without disrupting other integrations. It also gives you clear visibility in the dashboard: the request count and last-used timestamp appear per key, so you can spot unused or unexpectedly active keys quickly.

Use the read scope by default and only upgrade to write or admin when your integration specifically requires it. A key with read scope cannot accidentally delete resources or create duplicate records, even if there is a bug in your code. Applying the principle of least privilege to API keys is one of the simplest ways to protect your UniLink data.

If you are building a multi-tenant application where each of your customers has their own UniLink account, each customer must generate their own API key from their own dashboard. UniLink API keys are scoped to a single account — a key from account A cannot access account B's data regardless of scope. This is a security feature, not a limitation.

Store keys in environment variables that are injected at deployment time rather than baked into container images or build artifacts. Tools like AWS Parameter Store, HashiCorp Vault, Vercel Environment Variables, or GitHub Actions Secrets all support this pattern. The key should never appear in logs, error messages, or stack traces — add scrubbing rules to your logging library to redact strings matching the sk_live_ prefix pattern.

Troubleshooting

• Generate API keys from Settings → API in the dashboard — copy the key immediately, it is shown only once.
• Every request needs the Authorization: Bearer YOUR_KEY header — missing or wrong headers return 401.
• Three scopes are available: read, write, and admin — use the least-privileged scope your integration needs.
• Create a separate key per integration for easier auditing, revocation, and incident response.
• Store keys in environment variables — never in source code, logs, or public repositories.