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.
| Field | Required | What it does |
|---|---|---|
| Connection name | Yes | Display 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 URL | Yes | The endpoint HighAdvocacy fires reward payloads to. Must be unique inside the workspace: the same URL cannot be used by two different connections. |
| Custom headers | Optional | Key/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.

Status: Active vs Needs attention
Every connection has one of two statuses.
| Status | Meaning | How it is set |
|---|---|---|
| Active | Healthy. Last delivery or test passed. | Set when the connection is created, and re-set on every successful delivery or test. |
| Needs attention | The 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:
- Read the signing secret from your HighAdvocacy workspace settings.
- On each request, read the signature header HighAdvocacy sends.
- Re-compute the signature over the raw request body using HMAC SHA-256 and your signing secret.
- 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:
rewardTypeis the reward’s type at fire time (gift_card,credits, orcustom).rewardAmountis the numeric value, not the formatted label.extrascarries any key/value pairs you set on the reward. Use it for routing fields likecost_center,region, orprovider_product_id.isTestistruewhen the payload was triggered by a Test connection action andfalsefor 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:
- The send shows up in Activity with status
Failed, the response code, and the error body. - The connection switches to
Needs attentionwith the amber banner. - 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:
- Open each reward attached to the connection and either change its connection or change its delivery to
Manual by team. - Return to Connections and delete the row.
Deleting a connection does not remove past Activity entries that fired through it. The history stays.
Related docs
- Reward catalog: the reward shape and how it references a connection.
- Activity: the live log of every reward send.
- Snapshot and history: how snapshots survive connection URL changes.