Build an unlock flow people understand.

1. Create a project and decide how users receive access.
2. Shape the gateway, offers, paid unlock, and optional integrations.
3. Save the project, open a test session, and publish the gateway link.

The editor preview is a live rendering of the gateway. It reflects the saved project values and most unsaved changes immediately.

Project name and slug identify the gateway in your dashboard and determine its public link. The title, subtitle, and reward description are visitor-facing content, so keep them short enough to scan on a phone.

Test sessions use the project settings stored on the server, so save before opening one when you need to verify the public flow.

Layout controls the structure of the gateway. Color scheme controls the visual tokens used by that layout. Custom overrides win over the selected scheme and stay attached when you switch layouts.

Pick the flow that matches where access should be delivered. The available Discord option appears after the Discord server flow is enabled in Project Details.

If a Discord bot flow is already configured for the project, it keeps working regardless of the reward type. The bot verifies codes, grants roles and expires access on its own, so switching to Code checked by your own API or bot or Redirect Website later will not disable or break your existing Discord configuration.

The email never names your project. A project's name is an internal label for your dashboard, so the message carries only the key, the instructions you wrote above, and UnlockHub's own footer.

API codes are designed for a bot, backend, or website that wants to control the final access decision. The project key is masked by default in the editor, with reveal, copy, and regenerate controls. Store it in your server environment and never expose it in browser code.

If your traffic and content are on Discord only, consider configuring the flow directly on UnlockHub. Enable the "Does your traffic come from a Discord Server?" checkmark to be able to configure Discord related settings, and set the reward type to"Code checked by Discord Bot and user gets role".

In theory, you can instead select the "Code checked by your own API or bot" reward type, use your own bot and embeds on your Discord, and check the validity of the codes yourself, completely bypassing the UnlockHub bot. That's just redundant.

Normally this reward type is used when your Community or Content platform is off Discord, or when you want your own backend to decide who gets in.

The API validation flow is:

1. Generate a project API key in Reward settings.
2. Let a completed session reveal its code.
3. POST the code to /api/reward/verify with the project key.
4. Grant access only when the response is valid and a seat is free.

curl -X POST https://www.unlockhub.xyz/api/reward/verify \
  -H "Authorization: Bearer YOUR_PROJECT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"key":"REWARD_CODE_FROM_SESSION","redeemerId":"end-user-123"}'

{"valid":true,"alreadyClaimed":false,"seatsTotal":25,"seatsLeft":24}

{"valid":false,"alreadyClaimed":true,"reason":"seats-exhausted"}

curl -X POST https://www.unlockhub.xyz/api/reward/verify \
  -H "Authorization: Bearer YOUR_PROJECT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"key":"REWARD_CODE_FROM_SESSION","consume":false}'

In this example, YOUR_PROJECT_API_KEY authenticates your server and REWARD_CODE_FROM_SESSION is the code the visitor received. Grant access only for a fresh seat; the second response means the key is fully used and nobody else may be let in.

consume: false is a pure read: it reports whether the key is still valid, how many seats are free and when the access ends, without redeeming anything. Use it when your own backend decides who gets in, for example to keep accepting one shared key for as long as the subscription behind it is active.

# first check: takes the key
{"key":"...","redeemerId":"user-42"}  →  {"valid":true,"alreadyClaimed":false}

# the same person checks again: already theirs
{"key":"...","redeemerId":"user-42"}  →  {"valid":true,"alreadyClaimed":true}

# anybody else
{"key":"...","redeemerId":"user-99"}  →  {"valid":false,"reason":"seats-exhausted"}

# every call is accepted, so you always ask first
{"key":"...","consume":false}  →  {"valid":true,"seatsLeft":null,"accessUntil":null}

# one call that consumes and hands out the access
{"key":"...","redeemerId":"user-42"}  →  {"valid":true,"alreadyClaimed":false}

Read accessUntil to know how long the access you just granted should last, and subscription to tell whether it follows a subscription. A key tied to a subscription answers valid: false with reason: "entitlement-ended" once that subscription stops paying, so nothing needs to expire on your side.

The access model controls whether visitors can use offers, a one-time payment, subscriptions, or a combination. Offer wait adds a delay before the free route becomes available. You can also choose how many tasks are needed for the free unlock. How long the granted role lasts is set per Discord server in the Discord configuration.

The editor shows the resulting one-time and monthly prices beside every tier, so you can check the regional pricing before saving. If discounts are disabled, visitors see the normal configured prices without a reveal animation.

Offer payouts are credited exactly as the provider reports them, and paid unlocks are credited for the amount that reaches the UnlockHub account after the card processor's fees. No commission is taken from either. The fee only applies at withdrawal: request $100 and you are paid $75, while the full $100 is what leaves your balance. If a sale is refunded or charged back, that credit is reversed. The customer keeps the access they were given.

Enable the Discord flow when a bot should verify codes and manage roles. Install the bot, choose the portal server and channels, then place the bot role above every role it must assign.

Refresh channels and roles after installing the bot. Discord only permits role assignment below the bot's highest role, so hierarchy is the first thing to check when a role is visible but cannot be granted.

Completion webhooks are optional server-to-server notifications for your own bot or backend. Configure the URL and shared secret in Misc settings; UnlockHub signs the payload so your receiver can verify it came from your project.

Your gateway link is served from a portal domain, not from the dashboard URL. Links live in Discord messages, descriptions and reuploads, so they have to keep working; keeping them on their own hostnames means a hostname that gets flagged can be replaced without touching the project.

There are two dashboards on purpose. Yours answers "how are my gateways doing", and the platform one answers "is the platform healthy". A single screen that silently changes meaning depending on who is looking is how numbers get misread. Both report a period against the one before it, so a number is never shown without something to compare it to.