# Reward availability Reward availability controls who can access a reward, when it’s available, and where it can be redeemed. These settings help you tailor reward visibility and usage across different audiences, timeframes, and redemption locations.


User availability	Limit rewards to specific audiences based on user profile or behaviour.	/files/HCAXoK01fW2RC2UdnqRf	/pages/qJOft0rbeJYb3RksZuZ7#user_availability_constraints
Schedule a reward	Set a start and end date/time to control when a reward is active.	/files/x2fsvWCs10w9EfeDRPqY	/pages/qJOft0rbeJYb3RksZuZ7#schedule-a-reward
Venue availability	Define where a reward can be redeemed (e.g. specific stores or venues).	/files/oXmOHf9u67jdcp1cr3R7	/pages/qJOft0rbeJYb3RksZuZ7#venue_availability

*** ## **User availability** One of the most useful features of the White Label Loyalty platform is the ability to control who can see or purchase a reward. This lets you create more tailored, targeted, or gamified experiences for your users. By default, all rewards are available to everyone—as long as they have enough points. But you can restrict availability in a few different ways: * **Limit by audience** Only users in a specific audience can see or purchase the reward. This is the most common option. * **Limit by tier** Only users in a specific tier (or higher) can access the reward. * **Reactor-only rewards** Keep the reward hidden from all users and use it only as part of a reactor (e.g. automatically issuing a reward on a user’s birthday). You can use one or more of these options at the same time, depending on how you want the reward to behave. {% tabs %} {% tab title="Limit by audience" %} ### Limit by audience You can control who sees and who can purchase a reward by linking it to specific audiences. There are two constraint types: * **Visibility** – The reward is only shown to users in selected audience(s). Others won’t see it at all. * **Purchasability** – The reward is visible to everyone, but only users in the selected audience(s) can purchase it. You can apply either constraint individually or combine both. #### Visibility Use the **Visible to audiences** setting to hide the reward from all users except those in the selected audience(s). Users outside the audience won’t see the reward anywhere. If this field is left blank, the reward will be visible to all users (unless restricted by other settings, like tier). #### Purchasability Use the **Purchasable for audiences** setting to limit who can purchase the reward. All users will still see the reward, but only eligible users will be able to purchase it. * The API indicates locked rewards with the `isLocked` field. * You can select multiple audiences, which operates as an 'OR' logic i.e. choosing two audiences means the user must be in one or the other, rather than needing to be in both. * If needed, add a message in the reward description or T\&Cs to explain why the reward is unavailable. * In our white label interfaces, the Loyalty Microsite and Mobile App, users will see a lock icon over rewards they do not meet the purchasability criteria for. * If no audience is selected here, the reward is purchasable by everyone (unless other restrictions apply). {% endtab %} {% tab title="Limit by tier" %} ### Limit by tier You can limit a reward to users in a specific tier or higher by selecting a tier from the Tier dropdown. Users below the selected tier won’t be able to see or purchase the reward. {% endtab %} {% tab title="Reactor-only rewards" %} ### Reactor-only rewards If a reward is not intended for users to view or purchase themselves—such as rewards that are given automatically—you can hide it entirely using the **Purchasable** toggle. * When **Purchasable** is set to **OFF**, the reward is hidden from all users and cannot be purchased manually. * This overrides any audience or tier visibility settings. This is useful when [rewards are distributed through reactors](/product/loyalty-engine/reactors/reactions.md#give-reward) only—for example: > A £10 digital gift card is automatically given to users on their birthday via a reactor. Since it’s not meant to be browsed or claimed, it should not appear in the reward list. > {% endtab %} > {% endtabs %} *** ## **Schedule a reward** You can set a start and/or end date for when a reward is available. This is useful for preparing rewards ahead of a campaign or limiting availability to a specific timeframe. * In the Loyalty Console: * Rewards with a future start date appear in the **Scheduled** tab. * Rewards with an end date in the past (or that have been archived) appear in the **Ended** tab. * Once a reward is active, the **Available from** date can’t be changed. *** ## Venue availability Venue availability lets you associate a reward with one or more of your [venues](/product/modules/venues.md). This is mainly used in loyalty programs that integrate their POS system with our [voucher management system](/product/loyalty-engine/rewards-and-points/rewards/reward-types/vouchers.md) to control where rewards can be redeemed. Important notes: * Venue availability does not restrict a user’s ability to view or purchase a reward. * It is used to both indicate and validate where a reward can be redeemed. If a user tries to redeem a voucher at a venue not listed in the reward’s availability, **the validation will be rejected.** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://kbase.whitelabel-loyalty.com/product/loyalty-engine/rewards-and-points/rewards/reward-availability.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.