> For the complete documentation index, see [llms.txt](https://kerno.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kerno.gitbook.io/docs/portal/integrations.md).

# Integrations and API keys

Create an API key for non-interactive sign-in, connect GitHub, and pick up the CI workflow from the portal.

The portal's **Settings** section is where you connect Kerno to the rest of your toolchain.

### API key

**Settings → API Key** issues your personal key for the organization you have selected, so you get one key for each organization you belong to. Choose when it expires as you create it, from one hour to never. The expiry can't be changed later, so delete the key and create a new one to change it. The card tells you when a key has expired or is inactive.

The key exists for signing in where a browser cannot open, such as CI or a remote shell. The card gives you a ready-to-copy `kerno login --api-key` command with your key in it. You can also set the key in the environment, and the CLI authenticates on its own:

```bash
export KERNO_API_KEY=<your key>
export KERNO_ORG_ID=<organization id>   # optional, when you belong to several
kerno init -w /absolute/path/to/your/repo
```

`KERNO_ORG_ID` picks the organization when your key belongs to more than one.

{% hint style="warning" %}
An API key authenticates as you. Keep it in your CI provider's secret store, and delete it from the portal if it leaks.
{% endhint %}

### Integrations

**Settings → Integrations** is where Kerno meets the places your code lives and runs.

**CI setup.** The **Run Kerno in CI** card gives you one workflow file to copy into your repository. It first asks you to add your own API key as the `KERNO_API_KEY` repository secret, and shows the key so you can copy it. The workflow replays your Kerno tests on every pull request. After a merge to main that changes `.kerno`, it sends main's tests to Kerno. Run it once by hand to send the first snapshot. Without the key, the pull request check still runs and nothing is sent to Kerno. The key is yours, so if you leave the organization or delete it, Kerno stops receiving data from the repository until a teammate adds theirs. With GitHub connected, the card hands out a workflow that only replays, because the GitHub App syncs main. The full walkthrough is in [How to Run your Baseline Tests in CI](/docs/guides/run-tests-in-ci.md).

**GitHub.** Where it is available, connecting the Kerno GitHub App to your GitHub organization lets Kerno see the repositories you choose. Only the organization owner can connect or disconnect it. Kerno then records each repository's default branch on every push and backfills its history, so your CI workflow only needs to replay.

The card shows the connected account and the repositories Kerno can see. **Manage repositories** opens GitHub to add or remove them. Repositories you add are synced automatically, and removed ones stop syncing. Under each repository, a line shows the sync in progress, the commit last synced and when it was committed, or why a sync failed. A failed sync clears on the next push to the default branch, or contact support to re-run the history sync.

When the App needs a new permission, the card names it, and **Review on GitHub** lets an owner of your GitHub organization accept it.

Disconnecting revokes Kerno's access, and deleting a Kerno organization revokes it as well.

### What's next

* [Analytics](/docs/portal/analytics.md) to see how testing is going across your repositories.
* [Organizations and Teams](/docs/portal/organizations-and-teams.md) to manage members and roles.