> For the complete documentation index, see [llms.txt](https://docs.abbey.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.abbey.io/reference/linking-application-identities-into-abbey/supported-application-identity-types-and-schemas.md).

# Supported Application Identity Types and Schemas

## Identity Linking JSON Shapes

Identities are linked by POSTing to the `/v1/users/<userID>/apps` endpoint. Payloads are of the following shape:

```
{"type": "<application type>", "data": { ... application data ... }}
```

The `data` payload of each application type must contain certain keys that Abbey uses to make sure that an application has had its data linked properly.

For more details on APIs used to link apps, take a look at <https://developers.abbey.io/#operation/createAppData>.

## Application Identity Types

| Application Type    | Application Name    | Required Keys      |
| ------------------- | ------------------- | ------------------ |
| `aws_iam`           | AWS IAM Account     | `account_id`, `id` |
| `aws_identitystore` | AWS Identity Center | `id`               |
| `github`            | Github              | `username`         |
| `okta`              | Okta                | `user_id`          |
| `google`            | Google Cloud        | `id`               |
| `googleworkspace`   | Google Workspace    | `email`            |

Note that `aws_iam` is a special application type. `account_id` *must* be unique.

## Custom Identity Types

Any identity type not covered in the above table is considered a custom identity types. There is no set of required keys needed to link application identity data for a custom identity type. For example the below payload:

```json
{"type": "my-custom-app", "data": {"foo": "bar"}}
```

now allows references of the form:

* `.user.my-custom-app.foo` in grant kits
* `data.user.my-custom-app.foo` in policy code