Why snapshots exist

When a reward fires, HighAdvocacy copies its values onto the issued reward record. From that moment on, the reward issued to that submitter is decoupled from the catalog entry it came from.

The point of this is trust. You can edit a reward in the catalog as often as you want without surprising the people who already earned the older version. A submitter promised 100 Credits at submission time gets 100 Credits even if you bump the catalog to 150 Credits an hour later.

It also keeps retries predictable. When a webhook send fails and you retry, the payload that goes out is the snapshot, not the current catalog. The endpoint receives exactly what was promised to that submitter, every time.

What gets snapshotted

When a reward fires, the issued reward record stores:

Reward type (gift_card, credits, or custom).
Amount and, for gift cards, currency.
Name and description (the user-facing description if present, otherwise the name).
Value mapping (for custom rewards: the key and label).
Extras (any custom key/value pairs).
Connection URL at fire time.
Custom headers at fire time.

The activity row, the detail drawer, and the webhook payload all read from this snapshot.

What stays current

Not everything is snapshotted. Some pieces always read from the live workspace state:

Workspace signing secret. Signature verification uses the current secret. Rotating it means past signatures no longer verify, so coordinate the rotation with your endpoint.
Workspace metadata (workspace name, plan, ids that are not part of the reward payload itself).

The reward content the submitter was promised is locked. The transport-layer secret is not.

Editing a reward attached to live campaigns

The catalog edit flow shows a confirm dialog when you change a meaningful field on a reward that is attached to at least one campaign:

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

Meaningful fields include reward type, amount, currency, custom value mapping, delivery type, and connection.

Cosmetic fields (name, internal description, user-facing description) save silently. They are not part of the snapshot semantics; they are read live by the catalog and the campaign reward pickers.

Reward value history

The reward edit page sidebar shows the most recent value snapshots for the reward, capped at 10 entries. Each entry includes the reward type, amount, currency, and (for custom rewards) the value mapping at that time. For example:

Reward value history 2 hoodies · Custom · payload key hoodie_quantity $25 · Gift card · USD

A new history entry is pushed every time you change a value field. The current value is the top of the catalog form; the history shows what was promised at earlier points in time. The section does not appear in the sidebar until the reward has at least one prior snapshot.

The reward edit page with the right-hand sidebar showing Delivery, Last edited, Used by campaigns, and Last sent. The Reward value history section appears here once the reward has been changed.

The history is enough to answer “what did the people who submitted last week actually receive?” without digging through individual submissions. It is not a full diff: cosmetic field changes are not recorded.

What the snapshot rule means for retries

When a webhook send fails and you retry it (per-row or in bulk), the retry payload is the original snapshot, not the current catalog. This holds even if:

The reward’s amount has changed in the catalog.
The connection’s URL has been changed (the retry hits the snapshotted URL).
The reward has been deleted from the catalog (the snapshot still lives on the issued record).

The endpoint receives the same payload the original attempt sent, plus a higher attempt count and a fresh timestamp.

If you want the new amount to go to a submitter whose original send failed, do not retry. Reach out to the submitter manually and queue a new reward through whatever process you use off-platform.

Why there is no manual override on an issued reward

Once a reward is issued, the snapshot is the source of truth. You cannot edit the snapshotted values from the Activity detail drawer.

This is intentional: it keeps the rule simple and predictable. Issue-time wins, every time. If you need to make something right with a submitter, do it off-platform.

Reward catalog: where rewards are defined and edited.
Connections: why the snapshotted URL survives connection changes.
Activity: where snapshots are visible per send.