> ## Documentation Index
> Fetch the complete documentation index at: https://docs.repdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Redirect Hashing

> Secure return redirects from your survey platform to Research Desk using SHA-256 or SHA-512 hashing.

Redirect hashing validates that return redirects from your survey platform to Research Desk were not tampered with. Without this protection, fraudsters can fabricate complete URLs and collect incentives without taking surveys.

<Note>
  Redirect hashing requires implementation in your survey programming platform. Contact [clientsuccess@repdata.com](mailto:clientsuccess@repdata.com) to enable hashing on your account or if you do not see **Enable Hashing on Return Redirects** on surveys.
</Note>

## Why it matters

Return redirects (arrow #3 in the respondent flow — from your survey back to Research Desk) are the primary vulnerability for **ghost completes**. Hashing secures this connection so only redirects generated with your account's secret key are accepted.

Research Desk also supports **COMPLETE API** respondent validation for accounts that need server-side validation. See [Admin and User Management](/research-desk/getting-started/04-admin-and-users) for secret key access.

## How hashing works

<Steps>
  <Step title="Generate hash">
    Your survey platform hashes the full redirect URL **including** the secret key (`sk`). Research Desk supports **SHA-256** or **SHA-512**.
  </Step>

  <Step title="Send hash">
    Append the hash as parameter `hk` on the redirect URL sent to the respondent. The secret key must **not** appear in the final URL.
  </Step>

  <Step title="Verify">
    Research Desk independently hashes the URL (with `sk`) and compares it to the received `hk` value.
  </Step>

  <Step title="Accept or terminate">
    Matching hashes allow the respondent through. Mismatches terminate the session.
  </Step>
</Steps>

## Step-by-step setup

### 1. Get your secret key

Find your secret key in **Admin** — see [Admin and User Management](/research-desk/getting-started/04-admin-and-users). Keep it confidential.

### 2. Build the URL to hash

Construct the complete redirect with the respondent's RDUD and your secret key:

```
https://www.rdsecured.com/return?inbound_code=1000&rdud=<rdud_value>&sk=<secret_key>
```

Use the correct `inbound_code` for each outcome (1000 complete, 2000 terminate, 3000 security, 4000 over-quota).

### 3. Hash the URL

Pass the entire URL string (including `https` through the end of `sk`) through SHA-256 or SHA-512. Example SHA-256 output:

```
37ad45ef65a6f81aca682038b3c73780499a3f1afbb905fc5b4bc7bb16c52a81
```

Validation tools: [SHA-256](https://www.movable-type.co.uk/scripts/sha256.html) · [SHA-512](https://emn178.github.io/online-tools/sha512.html)

### 4. Redirect without the secret key

Send the respondent to Research Desk with `hk` instead of `sk`:

```
https://www.rdsecured.com/return?inbound_code=1000&rdud=<rdud_value>&hk=37ad45ef65a6f81aca682038b3c73780499a3f1afbb905fc5b4bc7bb16c52a81
```

### 5. Enable hashing on the survey

Toggle **Enable Hashing on Return Redirects** to ON in the New Survey or Edit Survey modal.

### 6. Test end-to-end

Run a complete path through **Test Survey** in an incognito window. Research Desk confirms successful hashing on the end page. An error page usually indicates a setup issue with the hash algorithm or URL construction.

## Platform implementation

Every programming platform implements hashing differently. If you need help:

* Review [Platform Redirect Guides](/research-desk/guides/18-platform-redirect-guides) for your survey tool
* Contact [clientsuccess@repdata.com](mailto:clientsuccess@repdata.com) — Rep Data teams can assist with platform-specific setup

## Related guides

* [Entry Links and Redirects](/research-desk/guides/04-entry-links-and-redirects)
* [Platform Redirect Guides](/research-desk/guides/18-platform-redirect-guides)
* [Troubleshooting](/research-desk/support/troubleshooting)