# Applications and keys

## Creating an application

Sign in, open Applications, and add one. You need a name; the URL is optional and is only used to show the site's icon beside the name.

The application page shows its keys as soon as it exists, and every client needs them before it will send anything.

## The two keys

Every client authenticates with two values, both on the application's settings page.

| Key | What it is |
| --- | --- |
| Ingest key | Lets a client post events to this application, and reaches nothing else in your account. Rotatable, and safe to ship in a browser bundle. |
| Project key | Says which application a report is filed against. |

In the Laravel client they are `LB_KEY` and `LB_PROJECT_KEY`. In the JavaScript packages they are `loginKey` and `projectKey`: those names are the packages' own and are older than the ingest key, but the value to give them is the one above.

## The DSN

A DSN is both keys and the endpoint in one string, which is easier to paste into a deployment tool than three separate variables.

```env .env
LB_DSN=https://login_key:project_key@www.larabug.com/api/log
```

Where a client supports both, the DSN wins: if `LB_DSN` is set, the separate keys are ignored.

## Where the keys can go

Both of them can go in a browser. That is what the ingest key is for: it opens exactly one thing, posting events to one application, and it cannot read an issue or delete one. Every JavaScript bundle that reports browser errors ships it, which is unavoidable and by design.

Narrow it further with the allowed origins on the same settings page, which is the list of sites a report is accepted from.

What does not belong in a browser is the account token the [HTTP API](/docs/integrations/http-api) reads with. That one is your account.

## Rotating a key

Rotate the ingest key from the application's settings. The old one stops being accepted immediately, so deploy the new one first if you would rather not lose the events in between.