# Check that your API key works for a team

```http
GET https://secure.yoprint.com/v1/api/store/{team_slug}/is_authenticated
```

- API version: v1
- Operation ID: `v1_public_misc_is_authenticated`
- Section: Account › [API key](https://developer.yoprint.com/reference/api-key.md)
- Web page: https://developer.yoprint.com/reference/api-key/v1-misc-is-authenticated/
- Authentication: `Authorization: Bearer YOUR_API_KEY`

Answers `200` with `{"is_authenticated": true}` when the key is valid and its owner is a member of the team in the path. It reads nothing else and changes nothing, so it is the cheapest way to test a key before you build on it.

- `401` means the key is missing, wrong or was reset.
- `404` means the team slug does not exist, or the key's owner is not a member of that team.

Send the key as `Authorization: Bearer YOUR_API_KEY`.

## Permission

Any valid personal API key whose owner belongs to the team.

## Side effects

- Counts as a use of the key: the "last used" time on your Profile page updates.

## Path parameters

- `team_slug` (string, required): Your team slug, shown as Team ID next to your API key in Profile. Example `your-team`.

## Request body

This operation takes no request body.

### Example request

```bash
curl 'https://secure.yoprint.com/v1/api/store/your-team/is_authenticated' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Accept: application/json' \
  -H 'X-Yoprint-Decimal-Format: exact-v1'
```

## Response

`200` Successful response.

Fields:

- `data` (object, required)
  - `is_authenticated` (boolean, required): Always true. Failures are 401 or 404, never false. Always `true`.
- `status` (integer, required)
- `success` (boolean, required)

Example response:

```json
{
  "data": {
    "is_authenticated": true
  },
  "status": 200,
  "success": true
}
```

## Errors

- `401` The API key is missing or wrong (`unauthenticated`).
  - When: No key was sent, or the key is wrong or was reset. Fix: Send `Authorization: Bearer YOUR_API_KEY` with the current key from your Profile page.
- `403` You are not allowed to do this. `api_access_not_in_plan`: your team's plan doesn't include API access (Pro and above, with an active subscription or trial), so every request answers this until the team upgrades. When your role lacks the permission the operation needs, the body is only `{"message": "Insufficient Permission"}`. Other refusals use the error envelope, with `unauthorized` or `user_is_not_authorized`.
- `404` Not found. `page_not_found`: the team slug is unknown, you are not a member of the team, or an id in the path is not one of this team's. `code: null`, with a message that starts "No query results for": there is no record with that id.
  - When: The team slug does not exist, or the key's owner is not a member of that team. Fix: Check the team slug, and use a key that belongs to a member of that team.

## Notes

- The response never says `false`. Treat any non-200 answer as "not authenticated for this team".
- A key belongs to a person, not to a team. The same key works for every team its owner belongs to; change the slug in the path.
- Send the key in one place only. If you send it more than once, the `user_api_key` query parameter wins, then a `user_api_key` body field, then the `Authorization` header; a wrong key in the first place found is not retried from the next.
- Only personal API keys work on the public API. Tokens issued to AI apps are refused with 401.
