Authentication

The Interlynk API authenticates every request with a security token sent in the Authorization header.

Token types

There are two kinds of token. Pick the one that matches how you will use the API.

	Personal token	Service token
Belongs to	A user	The organization
Role	Inherits the user's role	An explicit role you choose
Survives the user leaving	No	Yes
Prefix	lynk_live_...	lynk_service_live_...
Best for	Manual use, scripts you run yourself	CI/CD, automation, shared integrations

For CI/CD integrations, use a service token. A personal token stops working when the person who created it loses access or leaves the organization, which breaks the pipeline. A service token belongs to the organization and has its own role, so it keeps running independently of any one user.

Create a personal token

1. Log in to the Interlynk dashboard.

2. Click Settings in the left-hand bar.

3. Click Personal in the top right.

4. Click Security Tokens.

5. Click + to generate a new token.

Give the token a name and an expiration date. Pick the shortest expiration that fits your use case.

A personal token looks like this:

lynk_live_CgzGW2qLk5C73o7SgsKyBT3wVcm**********

Create a service token

Create a service token from your organization settings in the dashboard. A service token has two properties:

• A name, so you can identify it later.

• A role, which sets exactly what the token is allowed to do.

A service token looks like this:

lynk_service_live_CgzGW2qLk5C73o7SgsKyBT3wVcm**********

Give a CI/CD service token the least-privileged role that still lets the pipeline do its job. For a pipeline that only uploads SBOMs, a role without delete or admin rights is enough.

Copy the token as soon as it is generated. You cannot retrieve it again after you close the window. Store it as a secret in your CI/CD platform, never in the repository.

Token permissions

A personal token inherits the role of the user who created it. A token created by an admin has admin privileges. A service token uses the role you assign when you create it.

Either way, give the token the least privilege the integration needs.

Use the token

Both token types are used the same way. Send the token as a bearer token on every request:

Authorization: Bearer lynk_live_xxxxxxxxxxxxxxxxxxxx

Store it in an environment variable so it stays out of your shell history and your scripts:

export INTERLYNK_SECURITY_TOKEN="lynk_live_xxxxxxxxxxxxxxxxxxxx"

Verify it works

This request returns your organization's name. If the token is valid, you get a name back.

curl https://api.interlynk.io/lynkapi \
  -H "Authorization: Bearer $INTERLYNK_SECURITY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query": "query { organization { id name } }"}'

Response:

{
  "data": {
    "organization": {
      "id": "72219448-e3cf-47f4-8e54-49199fc47f52",
      "name": "Acme Corp"
    }
  }
}

If the token is missing or wrong, the API returns HTTP 401:

{
  "errors": [
    { "message": "Unauthorized", "extensions": { "code": "UNAUTHORIZED" } }
  ]
}

See Errors for the full list of failure modes.