> For the complete documentation index, see [llms.txt](https://docs.insurgrid.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.insurgrid.com/get-started/03-api-credentials.md).

# Get your API credentials

Where to create an InsurGrid API key, and what to do when a call is rejected.

Every call you make to InsurGrid is authenticated with an API key you create in your own dashboard. This page covers where to find it, what it looks like, and what the most common rejections mean.

***

## Create a key

In the dashboard, open **Settings → API keys**. Type a name for the key and select **Create API key**. Existing keys are listed below the form, each showing when it was created, when it was last used, and a **Revoke** button.

Name keys for where they'll be used — "CRM integration", "CI pipeline" — so you can tell them apart later and revoke one without guessing which is which.

> ⚠️ **The key is shown once.** It appears immediately after you create it and is **not shown again** once you refresh or leave the page. Copy it straight into a secrets manager or an environment variable.

There is no rotate. If a key is lost or you think it may have been exposed, **Revoke** it, create a new one, and update your application. Revoking takes effect on the next request — and stops any live embeds using that key too.

## Use it

Send the key as a bearer token on every request:

```
Authorization: Bearer YOUR_API_KEY
```

A key is a numeric id, a pipe character, then a secret — shaped like `4821|xWq3…`. Send the whole string, pipe included.

| Environment | API base URL                                   |
| ----------- | ---------------------------------------------- |
| Staging     | `https://phoenix-staging.insurgrid.com/api/v1` |
| Production  | `https://phoenix.insurgrid.com/api/v1`         |

***

## A key belongs to one environment

Staging and production are separate systems, with separate dashboards and separate data. **A key created in one will not work against the other** — it comes back `401 invalid_api_key`.

Create your staging key at `dashboard-staging.insurgrid.com` and your production key at `dashboard.insurgrid.com`, keep them in separate configuration, and when you go live change the base URL and the key together.

If a call is failing with `401` and the address looks right, this is the first thing to check. More in [Environments](/guides/environments.md).

## Forms and Loss Runs need an agency admin

For the Forms API, embed sessions and Loss Runs, the key must have been created by an **agency admin**. One created by any other user is rejected with `403 admin_required`, however correct the request is.

The Policy Comparison API doesn't require this — any valid key works there.

## The product has to be enabled too

A valid key is not sufficient on its own. Forms and Loss Runs are each enabled separately, so a `403 feature_disabled` means your key is fine and the product simply isn't switched on for the agent who owns it. Contact us and we'll enable it.

***

## Webhooks authenticate in the other direction

Your API key authenticates requests **you make to InsurGrid**. It plays no part in the requests **InsurGrid makes to you**.

When you register a webhook endpoint you separately choose how InsurGrid should prove a delivery is genuine — a signature, an API key of your own choosing, a bearer token, or basic auth, set per endpoint. See [Set up a webhook endpoint](/get-started/04-webhook-endpoint.md).

## Keeping credentials safe

* Store keys in a secrets manager or an environment variable — never hard-coded.
* Never put one in browser or mobile code, a public repository, a URL, or your logs.
* Use a separate key per integration, so you can revoke one without taking down the rest.
* Revoke immediately if a key may have been exposed. There's no way to rotate in place.

***

Next: [Set up a webhook endpoint →](/get-started/04-webhook-endpoint.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.insurgrid.com/get-started/03-api-credentials.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.