> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tyk

> Connect Tyk to Oleria to discover Dashboard users, user groups, Dashboard permissions, security policies, gateway API keys, OAuth clients, credentials, and audit-log activity, and take remediation actions in your Tyk organization.

Tyk is an API management platform from Tyk Technologies. Connect the Tyk Dashboard of a self-managed installation or of Tyk Cloud to Oleria to see who can manage your APIs and what can call them: every Dashboard user and the permissions they hold, user groups, security policies, and the gateway API keys and OAuth clients that act on their own. Oleria reads this data from the Tyk Dashboard API with the API key of a Dashboard user. You can review access to your Tyk organization and take action directly from Oleria.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Tyk organization:

* **Accounts** - every Dashboard user, with their name, email address, whether they're active, when they were created, when they last signed in, and when they last changed their password. Developers in the classic developer portal are also imported, with their email address, whether they're active, when they were created, and when they last signed in. Users with a Dashboard API key also show token authentication. The Dashboard user that Oleria connects as is marked as the integration's own account.
* **Administrators** - Dashboard users marked as an admin (`IsAdmin`), and users outside any user group with no permission restrictions at all, which Tyk treats as admins, are marked as administrators. A user in a user group takes admin from the group: they're an administrator if they're marked as an admin themselves, or if their group is an admin group.
* **Non-human identities** - gateway API keys and OAuth 2.0 clients. Each key shows its alias, whether it's active, when it was created, last updated, last used, and expires, and the APIs it grants. A key without an alias is named `key` followed by the start of a hash. Each OAuth client shows its name, client ID, the API it belongs to, its redirect URI, and when it was last used. On Tyk Cloud, Tyk's own **Tyk System Integration User** is imported as a system account.
* **Credentials** - each Dashboard user's Dashboard API key, each gateway key, each OAuth client secret, and the certificates stored in the Dashboard. Gateway keys are shown as a password for basic-auth keys, a key pair for JWT keys, a certificate for keys bound to a certificate, or an API token. Certificates show their expiry date and fingerprint, and are linked to the keys bound to them. Oleria imports only metadata, such as the type, status, expiry date, and when a key or client secret was last used. It never imports or stores secret values. The Dashboard's user list includes each user's Dashboard API key, which Oleria uses only to find its own user, and with key hashing off it uses each gateway key only to build a one-way ID.
* **Groups** - Dashboard user groups and their members. A Tyk user belongs to at most one group.
* **Roles** - one role for each Dashboard permission and level that any user or group holds, named like `users: read` or `keys: write`, plus an **Administrator** role. Each user group is a member of the roles its own permissions grant, and of **Administrator** only when the group is marked as an admin. Each security policy is also a role, described with the APIs it grants and its rate, quota, and key expiry limits. Gateway keys are members of the policies applied to them, and OAuth clients are members of their policy.
* **Ownership** - a gateway key or OAuth client that names a classic-portal developer is shown as owned by that developer.
* **Activity** - changes recorded in the Tyk Dashboard audit log, such as users, groups, keys, policies, and OAuth clients being created, updated, or deleted, users' access being revoked, Dashboard API keys being reset, passwords being reset, and certificates being added or removed. Each event shows the Dashboard user who made the change, the IP address, and the HTTP status. See [Activity](#activity).

Oleria refreshes this data on its [regular sync schedule](https://docs.oleria.com/integrations/overview.md#sync-model).

> [!NOTE]
>
> Oleria doesn't import API definitions, MCP proxies, analytics, webhooks, or API ownership as resources. It also doesn't connect to the Enterprise Developer Portal, the Tyk Cloud console, or Tyk AI Studio. See [Known limitations](#known-limitations).

## Prerequisites

* A Tyk Dashboard, self-managed or on Tyk Cloud, that Oleria can reach over HTTPS from the internet.
* For a self-managed Dashboard, an allowlist entry for its domain. Contact [support@oleria.com](mailto:support@oleria.com) before you connect. Tyk Cloud hosts under `tyk.io` don't need one.
* A Tyk administrator who can create Dashboard users and set their permissions.
* For activity, Tyk Dashboard 5.7 or later with the audit log enabled and stored in the database. See [Activity](#activity).
* Admin access to the Oleria workspace.

## Set up a Tyk Dashboard user

**1. Create a user for Oleria**

In the Tyk Dashboard, go to **System Management** > **Users** > **Add User** and create a dedicated user for Oleria. Oleria acts with this user's permissions, both when it syncs and when it runs [remediation actions](#remediation-actions). We recommend selecting **Account is Admin**.

If you don't want to use an administrator, grant the permissions in the table below. The user needs at least read on `users` and `user_groups`.

**2. Copy the Dashboard API key**

Go to **System Management** > **Users**, select **Edit** for the user, and copy the value under **Tyk Dashboard API Access Credentials**. This is the Dashboard API key you'll paste into Oleria. It belongs to this user, so Oleria can do only what this user can do.

> [!NOTE]
>
> Store the API key securely, and rotate it per your organization's security policy.

> [!NOTE]
>
> The exact location of these settings can change between Tyk versions. If the steps above don't match what you see, refer to Tyk's documentation on Dashboard users and user permissions.

The integration needs these Tyk Dashboard permissions. An administrator has all of them.

| Oleria needs to | Tyk permission |
| :- | :- |
| Connect, and read Dashboard users and their permissions | `users: read`. Required. |
| Read user groups | `user_groups: read`. Required. |
| Read security policies | `policies: read` |
| Read gateway API keys | `keys: read` |
| Read OAuth clients | `apis: read` and `oauth: read` |
| Read certificates | `certs: read` |
| Read classic-portal developers | `portal: read` |
| Read SSO profiles | `idm: read` |
| Read activity | `audit_logs: read` |
| Read when gateway keys and OAuth clients were last used | `analytics: read` |
| Activate, deactivate, and delete users | `users: read` and `users: write` |
| Create users, and change their permissions or group | `users: read`, `users: write`, and `user_groups: read` |
| Create groups | `users: read`, `user_groups: read`, and `user_groups: write` |
| Disable gateway API keys | `users: read`, `keys: read`, and `keys: write` |

If the user can't read users or user groups, the sync fails. If it can't read policies, keys, OAuth clients, certificates, developers, SSO profiles, the audit log, or analytics, Oleria skips that data and syncs the rest.

## Connect Tyk to Oleria

**1. Open the integration**

Go to your Oleria workspace, select **Integrations**, then select the **Tyk** tile.

**2. Complete the connection form**

Fill in the connection form:

| Field | Notes |
| :- | :- |
| Dashboard URL | Required. The https address of your Tyk Dashboard. For a self-managed Dashboard, include the port and any path, for example `https://dashboard.example.com:3000`. For Tyk Cloud, enter the address of your control plane's Dashboard, a host under `tyk.io`. Oleria adds `https://` if you leave it out and removes a trailing `/api`. The host must be a full domain name. IP addresses and addresses with credentials, a query, or a fragment aren't accepted. You can't change this after you connect. |
| Dashboard API key | Required. The **Tyk Dashboard API Access Credentials** of the user you created. |

**3. Confirm the connection**

Select **Authenticate**. Oleria reads the Dashboard's user list and a page of user groups with the API key, finds the user the key belongs to, and identifies your Tyk organization before saving the integration.

> [!NOTE]
>
> **Authenticate** checks that the user can read Dashboard users and user groups, the two required permissions. It doesn't check the others. Confirm the data after the first sync, as described in [Verify the integration](#verify-the-integration).

> [!NOTE]
>
> You can connect each Tyk organization to Oleria once. If the user can see several organizations, Oleria imports only the organization of the user the API key belongs to. To connect a different organization, add a new integration.

## Verify the integration

Confirm the Tyk instance appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. The integration's **Capabilities and operation readiness** section shows **Read users**, **Read groups**, and **Read roles**, and checks them against your Dashboard user: **Read users** needs `users: read`, **Read groups** needs `user_groups: read`, and **Read roles** needs `users: read` and `policies: read`. After the first sync completes, you can review the discovered accounts, non-human identities, credentials, groups, and roles in your Oleria workspace.

## Edit the integration

You can change the **Dashboard API key** of an existing integration, for example to rotate it. Select **Update** to validate and save your change.

* To keep the stored key, leave **Dashboard API key** empty.
* You can't change the **Dashboard URL** of an existing integration. To connect another Dashboard, add a new integration.
* The new key must belong to a user in the same Tyk organization. Oleria refuses a key from a different organization.

## Activity

Oleria imports activity from the Tyk Dashboard audit log. Tyk offers the audit log API on Dashboard 5.7 and later, when the audit log is enabled (`audit.enabled`) and stored in the database (`audit.store_type` set to `db`). The Dashboard user also needs `audit_logs: read`. If the audit log isn't enabled or the user can't read it, Oleria imports no activity and syncs everything else.

* The audit log records Dashboard API requests. Oleria imports only changes (`POST`, `PUT`, `PATCH`, and `DELETE` requests), so read requests aren't imported.
* Changes made by the Dashboard user that Oleria connects as, including Oleria's own remediation actions, aren't imported. Use a dedicated user for Oleria so that no one else's changes are hidden.
* Oleria matches each event to a Dashboard user by email address. If no user has that email, for example because the user was deleted or signs in through SSO without a Dashboard user, the event keeps the email address but isn't linked to an account.
* Requests that Tyk rejected show their HTTP status as an error.
* Changes that Oleria doesn't recognize, such as changes to API definitions or webhooks, are imported as custom activity.

## Remediation actions

Oleria can take these actions in Tyk. Each one runs as the Dashboard user whose API key you connected.

| Action | Applies to | What it does | Revert |
| :- | :- | :- | :- |
| Disable user accounts | Dashboard users | Marks the user inactive. In Tyk, an inactive user can't use the Dashboard or the Dashboard API, and is signed out of all Dashboard sessions. | Supported - activates the user again. |
| Enable user accounts | Dashboard users | Marks the user active. | Supported - deactivates the user again. |
| Add user to role | Dashboard users | Grants the user a Dashboard permission at the role's level, or makes the user an admin for the **Administrator** role. | Supported - removes the permission. |
| Remove user from role | Dashboard users | Removes the permission from the user. Other permissions are kept. | Supported - grants the permission again. |
| Add user to group | Dashboard users | Puts the user in the user group. | Supported - removes the user from the group. |
| Remove user from group | Dashboard users | Takes the user out of their user group. | Supported - puts the user back in the group. |
| Create group | User groups | Creates an active user group with the name you give. The group has no permissions and isn't an admin group. | Supported - deletes the group, if no user has joined it. |
| Create user | Dashboard users | Creates a user with the name and email address you give, in the one user group you choose, with that group's permissions and the password you give or a generated one. The user is inactive unless you choose to activate it. | Supported - deactivates the user Oleria created. |
| Delete user | Dashboard users | Deletes the user from the Dashboard. If the user is already deleted, the action makes no change. | Not supported. |
| Disable NHI accounts | Gateway API keys | Marks the key inactive. Oleria keeps the key's quota when it changes it. | Supported - activates the key again. |

> [!NOTE]
>
> The **Remediations** page offers **Revert** only for **Disable user accounts**, **Remove user from group**, and **Disable NHI accounts**. The integration supports the other reverts in this table, but the Remediations page doesn't offer them yet. Oleria can revert only an action that completed or partially completed, never one that failed.

> [!WARNING]
>
> **Delete user** can't be undone. Tyk can't restore a deleted user through its API. Before you delete a user, consider disabling them instead.

Keep these limits in mind when you use these actions:

* Before each action, Oleria checks that its Dashboard user has the permissions listed in the [permissions table](#set-up-a-tyk-dashboard-user). A `write` permission counts as `read`. Oleria skips this check when its user is an administrator, belongs to a user group, or can't be identified. Tyk doesn't document whether a user with `users: write` but without admin can grant permissions it doesn't hold itself, so we recommend an administrator for actions.
* Oleria reads the user or key before it changes it. If it's already in the requested state, the action makes no change, and reverting it makes no change either.
* Oleria sends each change once, then reads it again to confirm. If the response is lost and the change doesn't show when Oleria reads it again, the action fails and reports that the change may have been applied. Check the Dashboard before you run the action again.
* Oleria refuses to change its own Dashboard user, because the change could disconnect the integration. It also refuses to disable, delete, or remove permissions or the group of Tyk Cloud's **Tyk System Integration User**.
* Oleria finds its own Dashboard user by matching the API key against the Dashboard's user list. If it can't, for example because `security.forbid_admin_view_access_token` hides other users' keys, Oleria refuses **Disable user accounts**, **Delete user**, **Remove user from group**, and **Remove user from role**, because the target could be its own user. **Enable user accounts**, **Add user to role**, **Add user to group**, and **Create user** still run, but only reverting **Create user** works. The others' reverts are refused for the same reason, and reverting **Add user to group** makes no change and says why.
* A Tyk user belongs to only one group. **Add user to group** refuses a user who is already in another group, because the change would move them. Remove the user from that group first. Tyk may also apply the group's permissions to the user, so review the user's permissions after a group change.
* Tyk treats a user with no permissions as an admin. Oleria refuses any change that would leave a user with no permissions. It also refuses to add a single permission to a user with no permissions of their own: outside a group that would remove their admin access, and for a user in a group, Tyk doesn't document how a personal permission combines with the group's. Set that user's permissions in the Dashboard instead. It also refuses to remove **Administrator** from a user who is an admin only because they have no permissions, including a user whose user group no longer exists. Oleria reads a user's admin access the same way in its actions as in the sync.
* Once a user leaves their group, Tyk would treat them as an admin if they have no permissions of their own. So when **Remove user from group** takes such a user out of their group, Oleria also sets their permissions to `{"IsAdmin": "false"}`, which grants nothing and isn't admin. Undoing **Add user to group** does the same. Tyk doesn't document whether it keeps that setting. If Tyk shows the user as an admin after the change, Oleria puts the user back in the group with their previous permissions, and the action fails and says so.
* A user holds either `read` or `write` on each object. **Add user to role** refuses to grant one level while the user holds the other on the same object. Remove that role first.
* Security policy roles are held by keys and OAuth clients, not Dashboard users, so you can't add a user to a policy role or remove them from one.
* **Create user** needs exactly one user group, and that group can't be an admin group or have an empty permission map, which Tyk treats as admin. Oleria never creates an administrator. A group made by **Create group** is accepted, but it grants nothing, so the new user has no Dashboard access until you add permissions to the group. **Create user** sets the password you give, or a generated one if you choose to generate a password. Oleria never shows or logs the password, including a generated one. If you give no password, the new user signs in through SSO or after an administrator resets their password. If a user with the same email address already exists, the action makes no change.
* **Disable NHI accounts** applies only to gateway API keys. Oleria can't disable OAuth clients, because Tyk can only delete them, which also drops their tokens and can't be undone. It also can't disable Tyk Cloud's **Tyk System Integration User**, which runs Tyk Cloud's control plane.
* **Disable NHI accounts** addresses each key by its hash. If key hashing is off and the Dashboard lists a key without a hash, Oleria refuses to disable it, because the key ID would be the secret itself. Tyk must also allow keys to be updated by their hash (`enable_update_key_by_hash`). If the key isn't in the first 10,000 pages of the Dashboard's key list, Oleria can't find it: disable it in the Dashboard instead.
* **Create group** creates the group without permissions. Add them in the Dashboard under **System Management** > **User Groups**. If a group with the same name already exists, the action makes no change. Reverting deletes the group only while no user is in it. Otherwise the revert makes no change and says why.
* Oleria can't revoke user sessions in Tyk. Disabling a user already signs them out of the Dashboard.

## Known limitations

* **No MFA.** The Tyk Dashboard has no built-in multi-factor authentication, so Oleria shows MFA as not required. MFA enforced by an SSO identity provider in front of the Dashboard isn't visible to Oleria.
* **SSO is never shown as required.** Tyk doesn't record which users sign in through SSO. If the Dashboard has any SSO profiles, Oleria shows SSO as configured for every Dashboard user. Password sign-in stays available alongside SSO, so Oleria never shows SSO as required. SSO shows as unavailable if the user can't read SSO profiles (`idm: read`), or if reading them fails for any other reason. The rest of the sync carries on.
* **Users who sign in only through SSO.** Tyk doesn't list SSO users who don't have a registered Dashboard user, so Oleria doesn't import them.
* **Group permissions.** Each group is shown as holding the roles its permissions grant, and each user as holding the roles of their own permissions. A group with no permissions isn't shown as an admin group. A user in a group who has no permissions of their own isn't shown as an admin, because the group's permissions apply to them. Tyk doesn't document this for users with Dashboard accounts. If a user's group no longer exists, the user is shown by their own permissions, so a user with none is shown as an admin. Tyk doesn't document whether deleting a group removes its users from it.
* **`write` doesn't imply `read` in Oleria.** Tyk treats `write` as including `read`, but a user with `users: write` appears only as a member of the `users: write` role.
* **Denied permissions aren't shown.** A permission set to `deny`, such as `owned_analytics: deny`, isn't imported as a role.
* **Hidden Dashboard API keys.** If `security.forbid_admin_view_access_token` is set, Oleria can't see other users' Dashboard API keys. Oleria then shows a Dashboard API key credential for every user, can't mark its own user, and imports its own changes as activity. Destructive actions are refused, as described in [Remediation actions](#remediation-actions).
* **Keys issued to OAuth clients.** Gateway keys that Tyk issued to an OAuth client are tokens of that client. Oleria shows the OAuth client and doesn't import these keys separately.
* **Key listing turned off.** If Tyk hashes keys and hashed key listing (`enable_hashed_keys_listing`) is off, as on Tyk Cloud, the Dashboard can't list gateway keys. Oleria then imports no gateway keys or their credentials, and syncs the rest.
* **OAuth client status.** Tyk has no status for an OAuth client, so a client shows as active when its API is active. Oleria doesn't show when an OAuth client was created.
* **Ownership by developers.** Oleria links an OAuth client to a developer through the client's `user_id` metadata. Tyk doesn't document what that field means, so confirm in Tyk before you act on it.
* **Last-used dates.** Oleria reads when each gateway key and OAuth client was last used from Tyk's analytics, looking back 90 days. It reads up to 5,000 keys and clients per sync, split between keys and OAuth clients, and stops after 45 minutes. Keys and clients with no traffic in that time, keys listed without a hash, keys and clients past the limit, and Dashboard API keys have no last-used date. If the user can't read analytics (`analytics: read`), analytics are off, or a lookup fails, Oleria leaves those dates empty and syncs the rest.
* **Sign-in activity.** Oleria imports Dashboard sign-ins and failed sign-ins if Tyk records them in the audit log. Tyk doesn't document whether it does. Password changes made by editing a user appear as user updates, and group and permission changes appear as updates to the user.
* **No AI agents.** Oleria doesn't collect AI agents in this version. The Dashboard API has no AI agent inventory. Tyk AI Studio is a separate product with its own host, users, and API key, and the Dashboard API key can't read it. Tyk recommends giving each AI agent its own API key or OAuth client and policy, and those keys and clients appear in Oleria as non-human identities.
* **Not connected.** The Enterprise Developer Portal has its own host and token, and the Tyk Cloud console has no public API for its users, teams, or organizations, so Oleria doesn't import them. Oleria doesn't use the Dashboard Admin API.
* **Self-managed and custom domains.** Oleria connects to Tyk Cloud hosts under `tyk.io`. A self-managed Dashboard, or a Tyk Cloud Dashboard on a custom domain, needs an allowlist entry for that domain first. Contact [support@oleria.com](mailto:support@oleria.com). Hosts that resolve to private or loopback addresses can't be connected. Oleria recognizes Tyk Cloud's **Tyk System Integration User** only on hosts under `tyk.io`. On any other host, a user with that name is imported as a person.
* **Rate limits.** Tyk doesn't document a Dashboard API rate limit. Oleria paces its requests to each Dashboard, 10 per second by default, and during a sync it waits and retries when the Dashboard reports it's busy. Actions aren't retried: if an action reports a rate limit, run it again later.

## Troubleshooting

| Message or symptom | What to do |
| :- | :- |
| The Dashboard API key was refused (HTTP 401) | Copy the key again from **System Management** > **Users** > **Edit** > **Tyk Dashboard API Access Credentials**. |
| The key's Dashboard user may not read Dashboard users | Grant the user `users: read`, or make it an admin. |
| Reading Dashboard users answered HTTP 404 | Check that the **Dashboard URL** is the address of your Tyk Dashboard, not of a Tyk Gateway. |
| The Dashboard is rate limiting this key | Wait a few minutes, then try again. |
| Dashboard URL must be an https\:// address with a host name and no credentials, query or fragment, or the Tyk Dashboard URL must be the https address of your Dashboard | Enter the `https://` address of your Dashboard with a full domain name, without a username, password, query, or fragment. IP addresses aren't accepted. |
| Could not determine the Tyk organization | Oleria can't find the user the API key belongs to, and the visible users belong to several organizations. Check that the key belongs to a user in the organization you want to connect, and that `security.forbid_admin_view_access_token` doesn't hide it. |
| The Dashboard URL of an existing integration cannot be changed | Add a new integration for the other Dashboard. |
| This API key belongs to a different Tyk organization than this integration | Use a key from a user in the organization this integration is connected to, or add a new integration for the other organization. |
| The API key must be the key itself | Paste the API key value from the Dashboard. |
| **Authenticate** fails for a self-managed or custom domain without a Tyk error | Contact [support@oleria.com](mailto:support@oleria.com) to allowlist the domain. |
| The sync fails with an HTTP 403 that has no Tyk message | Something in front of the Dashboard, such as a firewall or proxy, blocked the request. Oleria treats this as a failure instead of skipping data. Allow Oleria's requests through to the Dashboard. |
| The key's Dashboard user may not read user groups, or listing user groups needs `user_groups: read` | Grant the user `user_groups: read`, or make it an admin. |
| Policies, keys, OAuth clients, certificates, or developers are missing | The user can't read them, so Oleria skipped them. Grant the permissions in the [permissions table](#set-up-a-tyk-dashboard-user). |
| Gateway API keys are missing, though the user has `keys: read` | The Dashboard can't list hashed keys. Set `enable_hashed_keys_listing: true` in both the Gateway and Dashboard configuration (on Tyk Cloud, ask Tyk support). |
| Gateway keys or OAuth clients have no last-used date | Grant the user `analytics: read`, and check that the Gateway records analytics. A key with no traffic in the last 90 days has no date. |
| The sync fails because the OAuth clients of all OAuth-enabled APIs were unreadable | Check that the APIs still exist and that the user has `oauth: read`, then sync again. |
| No activity appears | Check that the Dashboard runs version 5.7 or later, that the audit log is enabled and stored in the database, and that the user has `audit_logs: read`. |
| The integration's Dashboard user lacks a permission | Grant the user the permission the message names, or make it an admin. |
| An action refuses because the integration's own Dashboard user could not be identified | `security.forbid_admin_view_access_token` hides the user's API key. Run the change in the Dashboard instead. |
| An action refuses to add a user who is already in another group | Remove the user from their current group first. |
| Removing a user from their group left them an administrator, so they were put back in the group and nothing changed | Tyk didn't keep the permissions Oleria set. Set the user's own permissions in the Dashboard, then run the action again. |
| A user was removed from their group and Tyk now treats them as an administrator, and putting them back failed | Restore the user's group or permissions in the Dashboard now. |
| An action refuses because it would leave the permission map empty | Grant the user another permission first, or disable the user. |
| An action refuses to assign a role because the user has no permission restrictions (admin) | The user has no permissions of their own, so Tyk treats them as an admin. Set their permissions in the Dashboard, or add them to a group. |
| An action refuses to assign a role because the user takes its access from a user group | The user has no permissions of their own and gets their access from their group. Change the group's permissions, or set the user's permissions in the Dashboard. |
| An action refuses to assign a role because the user holds the other level on that object | Remove the user's current `read` or `write` role on that object first. |
| An action refuses to remove **Administrator** because the user's permission map is empty | The user is an admin because they have no permissions. Set their permissions in the Dashboard instead. |
| **Create user** needs exactly one group | Choose one user group that has permission restrictions. |
| **Disable NHI accounts** refuses because the Dashboard returns no key hash | Turn on key hashing in Tyk, or disable the key in the Dashboard. |
| **Disable NHI accounts** reports the key isn't in the first 10,000 pages of the Dashboard key list | Disable the key in the Dashboard, or raise the Dashboard's `page_size` setting so the key list has fewer pages. |
| An action reports it may have been applied | Check the user or key in the Dashboard before you run the action again. |

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.