Skip to Content
RewardsConnections

What a connection is

A reward connection is a named webhook endpoint. Every reward with delivery type Reward connection references one connection. One connection can be shared by many rewards.

Pulling the endpoint out of the reward record gives you two practical wins:

  • One place to update the URL when your endpoint changes. Every reward keeps firing without re-config.
  • One place to see whether the integration is healthy. Status surfaces on the connection, not on every reward.

The Reward Connections tab lists every connection, lets you search by name, and filters by status (All statuses). The empty state copy reads No reward connections yet. Add a webhook endpoint to start sending rewards. with an Add your first reward connection CTA.

Connection fields

The Add reward connection form has three fields.

FieldRequiredWhat it does
Connection nameYesDisplay name only. Shows on every reward that uses this connection and on Reward Activity rows. The placeholder is Tremendous webhook to suggest the pattern.
Webhook URLYesThe endpoint HighAdvocacy fires reward payloads to. Must be unique inside the workspace: the same URL cannot be used by two different connections.
Custom headersOptionalKey/value pairs sent on every request. Values are masked in the UI after save. Use for an Authorization or API-key header your endpoint expects. Click + Add another for more rows.

If you create a new connection and enter a webhook URL that another connection in the same workspace already uses, the product blocks creation and tells you which connection already has that URL. The fix is to attach the reward to the existing connection rather than make a duplicate.

The Add reward connection form with Connection name, Webhook URL, Custom headers, and the Test reward connection and Create reward connection actions

Status: Active vs Needs attention

Every connection has one of two statuses.

StatusMeaningHow it is set
ActiveHealthy. Last delivery or test passed.Set when the connection is created, and re-set on every successful delivery or test.
Needs attentionThe last delivery or test failed.Set automatically on failure. Cleared on the next success.

When a connection is in Needs attention, the connection’s edit page shows an amber banner:

Recent delivery failed. Check the URL and auth, then run Test connection.

The banner clears on the next successful delivery or test.

Testing a connection

Click Test reward connection on the connection form (or edit page) to fire a synthetic reward payload (isTest: true) at the configured URL.

The test:

  • Uses the connection’s current URL and headers.
  • Includes the workspace signing secret signature (see below).
  • Records a single entry in Reward Activity tagged as a test, so it does not pollute real-reward counts.

Test success switches status to Active. Test failure switches status to Needs attention and surfaces the response code and body so you can debug.

Signature verification

Every reward payload is signed with the workspace’s signing secret from Settings → Security. The same pattern is used for team alerts, so if you have already verified those, the verification code is the same.

To verify on your endpoint:

  1. Read the signing secret from your HighAdvocacy workspace settings.
  2. On each request, read the signature header HighAdvocacy sends.
  3. Re-compute the signature over the raw request body using HMAC SHA-256 and your signing secret.
  4. Compare in constant time. If the signatures match, the payload is from HighAdvocacy.

Reject any request whose signature does not match. Rotating the secret invalidates older signatures, so do so only when both sides are ready.

Payload shape

Every reward send uses the same payload shape. Customers map this however they want on their endpoint.

{ "campaignId": "cmp_test_000000000000", "campaignName": "Test Campaign", "submissionId": "sub_test_000000000000", "rewardId": "rwd_...", "name": "$25 Amazon Gift Card", "user": { "userId": "usr_test_000000000000", "email": "[email protected]", "name": "Test User" }, "delivery": { "type": "connection", "connection": "Tremendous webhook" }, "platform": "G2", "section": "review", "rewardCategory": "webhook", "rewardType": "credits", "rewardAmount": 500, "rewardDescription": "AI Credits", "extras": {}, "status": "verified", "verifiedAt": "2026-06-04T08:01:15.244Z", "isTest": true }

A few notes on the fields:

  • rewardType is the reward’s type at fire time (gift_card, credits, or custom).
  • rewardAmount is the numeric value, not the formatted label.
  • extras carries any key/value pairs you set on the reward. Use it for routing fields like cost_center, region, or provider_product_id.
  • isTest is true when the payload was triggered by a Test connection action and false for real reward sends.

The reward edit form shows a live Payload preview with the current configuration so you can see exactly what the endpoint will receive before saving.

When a connection fails

A failed send moves through three surfaces:

  1. The send shows up in Activity with status Failed, the response code, and the error body.
  2. The connection switches to Needs attention with the amber banner.
  3. Every reward attached to this connection inherits the visible warning on its row in the catalog.

Recovery is usually:

  • Open the connection.
  • Check the URL and headers.
  • Click Test connection. If it passes, status returns to Active.
  • In Activity, click Retry all failed (N) to re-send the queued failures.

Retries use the snapshotted reward values, not the current catalog values. See Snapshot and history.

Deleting a connection

A connection cannot be deleted while any reward references it. To delete:

  1. Open each reward attached to the connection and either change its connection or change its delivery to Manual by team.
  2. Return to Connections and delete the row.

Deleting a connection does not remove past Activity entries that fired through it. The history stays.

Last updated on