What the catalog is for

The Reward Catalog is the list of every reusable reward your workspace has defined. Each row is one reward. Campaigns attach to a reward from this list, instead of configuring rewards inline on each campaign.

You set up a reward once. You attach it to as many campaigns as you want. When the reward needs to change, you edit it in one place and every future send uses the new values. Rewards that were already issued keep what they were promised. See Snapshot and history.

The catalog list shows: Name, Reward type, Value, Delivery, Last sent, and Used by (the campaigns attached). Sort any column, filter by All reward types or All campaigns, and search by reward name from the top of the page.

The Reward Catalog list with a row showing the Name, Reward type, Value, Delivery, Last sent, and Used by columns

What a reward is made of

The reward edit page is organized into three sections: Basics, Reward value, and Delivery. Each section has its own fields.

Basics

Field	What it does
Reward name	Internal catalog name used by your team and campaign builders. Shows on the catalog list, in the campaign reward picker, and inside the webhook payload.
Internal description (optional)	Visible only to your team. Useful for approval notes or fulfillment context. Advocates do not see it.

Reward value

Field	What it does
Reward category	One of `Custom`, `Credits`, or `Gift card`. The value fields below adapt to match it. (The catalog table shows this as the Reward type column.)
User-facing description	What the advocate sees on the widget, webpage, and reward picker before they submit.
Payload key (Custom only)	The stable field name sent in webhook and manual payloads. For example, `email_count` or `percent_off`.
Display label (Custom only)	The human-readable label shown in lists and Reward Activity. For example, `Additional Emails` or `% off`.
Reward value	The numeric value sent with this reward.

Delivery

Field	What it does
Delivery type	One of `Reward connection` (sends the payload through a connected webhook) or `Manual by team` (no automated send; appears in Reward Activity for the team to mark completed).
Connection (Reward connection only)	Which connection this reward fires to. If you have no connection yet, you can add one from the Reward Connections tab first. See Connections.

For Custom rewards, the form also surfaces a Popular custom ideas panel with common patterns (swag, discounts, feature unlocks) to help you decide what to set.

Reward categories in detail

Three categories cover every reward HighAdvocacy supports today. The category is set on the form as Reward category and surfaces on the catalog list as the Reward type column.

Gift card. A monetary value plus a currency. The unit shown to the advocate reads, for example, $25 Amazon Gift Card.
Credits. Account credit on your product. The unit reads, for example, 100 Credits.
Custom. Anything else: swag, premium feature unlock, early access, days of service, discounts. You define the Payload key (the stable field name in the payload) and the Display label (what advocates and operators see). A reward like 14-day premium extension becomes 14 days on the card and { "premium_days": 14 } in the payload.

Cash and discount, which existed as separate types in the previous inline rewards model, are gone. Cash maps to a Gift card with the relevant currency. Discount maps to a Custom reward with a percent payload key and label.

Delivery types

The delivery type decides what happens the moment a reward needs to go out.

Reward connection. When a submission is approved and qualifies for the reward, HighAdvocacy fires the payload to the connection’s webhook URL. Your endpoint provisions the reward (sends the gift card, applies the credits, triggers the swag fulfillment). Status, errors, and retries live in Activity.
Manual by team. No webhook fires. The reward appears in Activity with status Needs fulfillment and a Mark completed action. Your team handles delivery off-platform and clicks Mark completed when done. Use this when there is no API to call or when you want a human in the loop.

You can mix delivery types across rewards in the same workspace.

Creating a reward

Open Rewards in the sidebar, then Reward Catalog.
Click + Create reward.
Under Basics, give the reward a name and (optionally) an internal description.
Under Reward value, pick the Reward category, fill in a user-facing description, and set the value. For Custom rewards, also set the Payload key and Display label.
Under Delivery, choose Reward connection (and pick a connection) or Manual by team.
Click Save changes.

The reward is now in the catalog and ready to attach to any campaign.

Editing a reward

Open any reward from the catalog. The edit page shows the same form as create, plus a sidebar that summarizes the reward’s current state.

The sidebar shows:

Delivery: the current delivery type and a one-liner explaining what happens when it fires.
Last edited: how long ago the reward was last changed.
Used by N campaigns: the campaigns currently attached, each linking back to its campaign editor.
Last sent: when the most recent reward send was, or No rewards have been sent yet. if there is no history.
Reward value history (appears once a value field has been changed): the last 10 value snapshots. See Snapshot and history.

The reward edit page with the Basics, Reward value, and Payload details sections plus the right-hand sidebar showing Delivery, Last edited, Used by campaigns, and Last sent

Meaningful edits show a confirm dialog

When the reward is attached to at least one campaign and you change a meaningful field, the save action shows a confirm:

This reward is attached to N campaigns. The new values apply to future sends. Rewards already issued keep their original values.

Meaningful fields are: Reward category, Reward value, Currency, Payload key, Display label, Delivery type, Connection.

Cosmetic edits save silently

Reward name, internal description, and user-facing description save without a confirm dialog. They do not change what advocates receive, only how the reward reads.

Attaching rewards to campaigns

Every platform on a campaign can attach to one reward.

On a new campaign, the platform card’s reward picker pulls from the catalog. Pick a reward and it is attached.
One reward can be attached to many platforms across many campaigns. Editing the reward updates everywhere it is attached.
To detach, open the campaign and pick a different reward (or pick No reward).

There is no per-campaign reward override. If you need a different amount on the same idea, create a separate reward (for example, $10 Amazon Gift Card and $25 Amazon Gift Card as two catalog entries).

Deleting a reward

The catalog row has a delete action, but it is blocked while the reward is attached to any campaign. To delete:

Detach the reward from every campaign that uses it.
Return to the catalog and delete the row.

Deleting a reward does not remove submissions or Activity entries that were issued from it. Past entries keep their snapshot. The catalog row simply stops being available for new attachments.

There is no archive or pause state for rewards. The state of a reward is “exists or doesn’t.” Stopping a reward from being sent means removing it from the campaigns that attach to it.

What is not in scope yet

No per-person limit on a reward. Use the campaign’s submission cap.
No inventory cap on a reward.
No clawback action. Once a reward is delivered, the product does not have an undo. Coordinate with the recipient out-of-band if needed.
No payload template editor. The payload shape is fixed; Extras handles every customization the endpoint needs.
No reward analytics dashboard. Counts live in Activity; over-time charts are out of scope for this version.
No bulk import (CSV) of rewards.

These are intentional scope choices. Each one can come back as a small additive change if real demand shows up.

Connections: webhook endpoints that rewards fire to.
Activity: every reward send, with status, retry, and detail drawer.
Snapshot and history: what gets locked at fire time and how value history works.
Campaigns: where rewards are attached to platforms.