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

# Custom Key Tiers

Create a portfolio-wide tier hierarchy, assign keys and control minimum access.

Custom Tiers let you define access levels above Standard and share them across every service in your portfolio. Manage them under **Keys → Key tiers**. They become usable for assignments only after you explicitly activate the portfolio's hierarchy.

Existing Standard and Premium keys keep working. You do not need to regenerate keys or replace users' key strings to adopt tiers.

## Identity, rank and Premium

Each tier has a stable ID and slug, an editable display name and a position in the hierarchy. Reordering changes its rank, not which keys belong to it.

* **Standard** is protected at the lowest rank. It cannot be deleted or moved.
* **Premium** is protected against deletion, but can be moved above Standard.
* Custom tiers can be added, named and reordered. Their IDs and slugs remain stable.
* A portfolio can have up to 256 tiers, including Standard and Premium.

For example, from lowest to highest:

```
Standard → Supporter → Premium → Elite
```

| Key tier  | Passes a Premium minimum? | Premium status |
| --------- | ------------------------- | -------------- |
| Standard  | No                        | `false`        |
| Supporter | No                        | `false`        |
| Premium   | Yes                       | `true`         |
| Elite     | Yes                       | `true`         |

Moving Supporter above Premium makes existing Supporter keys Premium-or-higher without reassigning them. Moving it below Premium reverses that status. The display name alone never determines access.

## Publish and activate

1. Open **Keys → Key tiers** and create or edit the hierarchy.
2. Review the order and any optional key prefixes. Save your draft; saving alone does not change live access.
3. Preview the effects and resolve any reported blockers.
4. Publish the reviewed hierarchy. For a portfolio that has not enabled Custom Tiers, publication and activation are separate actions.
5. Activate only when the dashboard's readiness checks pass. Tier selectors then become available for that active portfolio.

For later edits to an active hierarchy, publication applies the reviewed new order. Preview again if the hierarchy changes while you are editing; do not reuse a stale preview to bypass a conflict.

{% hint style="info" %}
New tier-capable script builds need a published portfolio catalog. Rebuild older scripts through the normal dashboard workflow. Publication does not rewrite existing generated scripts or key strings.
{% endhint %}

### If activation is waiting

The dashboard can wait for older loader sessions, unsupported reachable builds or unfinished purchases/rewards. Follow the specific blocker shown. Let legitimate sessions or pending work finish, expire or restart normally; do not delete records just to make the check green.

Unknown legacy Premium baselines wait for a natural restart. For known old static sessions, a reorder requires a restart only if that session's **Premium status actually changes**. Losing minimum access still ends the session. New tier-capable builds update their tier values on a successful heartbeat.

## Assigning a product versus setting minimum access

These are different settings:

| Setting                              | Meaning                                                                                                         |
| ------------------------------------ | --------------------------------------------------------------------------------------------------------------- |
| A key's tier                         | The exact product the key belongs to.                                                                           |
| Service or script minimum            | The lowest tier allowed; higher-ranked tiers also pass.                                                         |
| Provider, drop, panel or reward tier | The exact tier generated by that source. It does not automatically become the highest tier the user can access. |
| Collaborator/issuer grant            | Which exact tiers someone may issue; moving a tier does not grant permission to issue unrelated tiers.          |

A key must satisfy both the current service minimum and the current script minimum. Expiration, revocation, HWID, session and required Discord-redemption checks still apply.

Keyless represents **Standard**, not unrestricted access. A minimum above Standard still needs a sufficient key, including custom tiers below Premium.

Leaving a provider tier inherited retains the legacy service-based Standard/Premium default. It does not silently issue an arbitrary custom minimum. When raising a minimum, also review the providers and purchase/reward sources that should issue qualifying keys.

## Existing keys and integrations

Older keys without an explicit tier retain their logical Standard or Premium identity through their existing Premium flag. No mass reassignment is necessary. Once Custom Tiers are active, current hierarchy comparisons apply to those identities too.

Legacy API requests using `is_premium` still choose the protected Standard/Premium tier. They do not choose a custom tier just because it is above Premium. Use an explicit tier ID for a custom product; see [REST API tier assignments](/rest-api/custom-tiers.md).

Existing key strings, expiry dates and HWID bindings are not changed just by publishing or reordering tiers. Previously started flows and purchases retain their captured product; changing today's default does not retarget an old purchase.

## Tier-specific key prefixes

Each tier has an optional **Key prefix** field with a preview. Set it in the hierarchy editor, review the changes and publish.

* A prefix can contain up to 32 Unicode characters, without whitespace, backticks or control characters.
* Both `ELITE` and `ELITE-` produce a new key beginning with `ELITE-`.
* Clearing the override restores the existing account-prefix fallback.
* The override belongs to the tier's identity and stays with it when it is renamed or moved.
* Overrides apply only while Custom Tiers are active and only to newly issued keys. Existing keys and replayed purchase results keep their original strings.

Without an override, keys currently at or above Premium use the account's Premium prefix when configured, otherwise its default prefix. Lower tiers use the default prefix. Moving a tier across Premium can therefore change the fallback prefix for future keys, but never existing key strings.

A prefix is a label, not an authorization check. Do not grant access by checking whether a key starts with `ELITE-`.

## Scripts, Discord and webhooks

* [Runtime variables](/roblox-sdk/runtime-variables.md): `JD_TIER` is the exact slug, `JD_TIER_NAME` is the display name and `JD_IS_PREMIUM` is the Premium-or-higher result.
* [Public SDK](/roblox-sdk/public-sdk.md): keep using `library.lua` and read `result.JD_TIER` and `result.JD_TIER_NAME` from `check_key()`. No SDK migration is required. Results describe the last verification, not a live protected loader session.
* [Discord bot](/discord-bot/setup.md): separate access whitelists from issuance permission, configure panel/reward products and choose exact or hierarchy role assignments.
* [Shop webhooks](/shop-webhooks/setup-and-config.md): select the purchased product's tier and keep a unique event ID for each purchase.

Discord role reconciliation is asynchronous. Saving a rank or role setting does not guarantee that Discord has already applied all role changes.

## Removing a tier

Standard and Premium cannot be deleted. A custom tier cannot be deleted while resources, grants or retained product records still reference it. Reassign or remove those references through their normal workflows first. A name change is preferable when the same product is simply being renamed.