Skip to main content

Overview

The secured integration builds on the advanced integration and moves the search call to your server. Instead of the browser calling the search API directly, the browser collects two values and hands them to your backend:
  1. pass_params(), the value produced by the Research Defender JavaScript library.
  2. A token from the get_token API that identifies the respondent.
Your server then calls the SEARCH v3 API with your private key, sending pass_params() as a request parameter and the token in a header named token. You can write the server side in any language. This page includes Python, Node.js, and C# samples.

How it works

1

Collect library data in the browser

Load rd_sys_util.min.js, call init(), wait for the datasets, then call pass_params().
2

Get a token

Call the get_token API from the browser. It returns a token that contains information about the respondent.
3

Send both values to your server

Post pass_params() and the token to an endpoint on your server, along with your survey number and the session ID.
4

Call the search API from your server

Call SEARCH v3 with your private key, send pass_params() as part of the request parameters, and send the token in the token header.

Prerequisites

  • A Research Defender publishable key, used in the browser for the library and get_token
  • A Research Defender private key, used only on your server for SEARCH v3
  • Your survey number (sy_nr) and the respondent’s session ID (sn_ud)
  • A server endpoint your page can call, ideally on the same origin as the page
  • A page served over HTTP(S). Opening the file directly from disk (file://) will not work.
Use your publishable key in the browser and your private key only on your server. Never include the private key in client-side code, and load it from an environment variable or secrets manager rather than source control.

Step 1: Get a token

Call get_token from the browser, after the library has been initialized.
string
GET https://{environment}.rtymgt.com/api/v3/respondents/get_token/{publishable_key}

Query parameters

string
Optional.
string
Optional.
Send the request with credentials (credentials: "include") so Research Defender cookies are included.

Example request

Example response

string
The token to send to your server.
string
When the token was generated, in UTC.
string
A status message, for example Token successfully generated.

Step 2: Browser integration

collectLibraryData() is the same function used in the advanced integration. checkWithBackend() posts surveyNumber, sessionId, pass and token to your server.

Step 3: Server integration

Your server receives the values from the browser and calls the search API.
string
GET https://{environment}.rtymgt.com/api/v3/respondents/search/{private_key}
The private key is part of this URL. Call this endpoint from your server only, and avoid writing full request URLs to logs.
string
required
The token returned by get_token.

Query parameters

string
required
The survey number.
string
required
The respondent’s session ID.
string
Set to "1" to enable.
string
Set to "1" to enable.
string
Set to "1" to enable.
string
required
The string returned by pass_params(). Send it as the name of a query parameter with an empty value.

Example response (excerpt)

The response also includes a Respondent object, which contains threat_potential.
search.py

Full samples

The samples below work together. The browser page posts to /api/rd-check on your server, and your server calls SEARCH v3.
secured-client.html
secured_server.py
secured_server.js
SecuredServer.cs
To run the Python or Node.js sample, put secured-client.html in a static folder next to the server file, set the RD_PRIVATE_KEY environment variable, start the server (python secured_server.py or node secured_server.js), and open http://localhost:8000. The Node.js sample requires Node.js 18 or later and npm install express.

Security recommendations

  • Keep the private key on your server. Load it from an environment variable or secrets manager, and never send it to the browser.
  • Keep the token and full request URLs out of logs. Treat the token as a credential. The SEARCH URL contains your private key, so log error types or status codes instead of full URLs.
  • Validate input on your server. Check the survey number and session ID before calling the search API.
  • Return only what the page needs. The samples return the full result for demonstration. In production, return a decision such as pass or fail.
  • Set a timeout on the search call, as the samples do, so a slow response never hangs your respondent flow.

Handling errors

Decide in advance what your survey should do when any step fails, so a temporary error never blocks legitimate respondents.