Use the Lookup API in DQE One Standalone

Once you've indexed records with an Index Records process (see Create and launch a process in DQE One Standalone), your own applications can query that index in real time over a small REST API — to power an autocomplete search, or to check for a duplicate before creating a new record.

Authentication

All 4 endpoints below use the same credentials as the MCP server and the rest of DQE One Standalone's REST API: HTTP Basic Auth with your account email and API token.

# Linux / macOS
echo -n "you@example.com:your_api_token" | base64

# Windows PowerShell
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("you@example.com:your_api_token"))

Find or regenerate your token under My Account > API Token. Send it as Authorization: Basic <base64 value> on every request.

Use a real, existing account's credentials — a well-formed header referencing an email that doesn't exist currently returns a server error rather than a clean "unauthorized" response.

These endpoints also allow cross-origin requests, so you can call them directly from a browser (for example, to build a live search-as-you-type box). If you do, keep in mind your API token would then be visible to anyone inspecting the page — for anything beyond an internal/trusted tool, call these endpoints from your own backend instead and keep the token server-side.

Which endpoint to use

GET /api/searchGolden also exists and takes the same parameters as searchRecords — but it currently runs the exact same literal/phonetic search, not a duplicate-matching search. Despite the name, it does not return a golden record or apply any matching rules. Use lookupGolden for that.

Identifying which index to query

Every endpoint needs to know which Index Records process's data to search. Provide one of:

• pid — the Index Records process's id.
• recordType — the name of the object/table it indexes (e.g. a Salesforce or Dynamics object name). Standalone resolves this to the most recently created, published, non-archived Index Records process that indexes that object — if none matches, you get an error rather than silently falling back to something else.

If neither is provided, the request fails with {"status":"error","error":"Either 'pid' or 'recordType' must be provided"}.

GET /api/searchRecords

Parameters (query string):

Returns a JSON array of matching records — each one is the full set of fields stored at index time, capped at 50 results (no pagination). There's no distance scoring: a record either matches one of the search tiers below, or it doesn't.

Standalone tries each tier in order and stops as soon as one of them returns enough results:

1. An exact match on a whole word.
2. A partial/prefix match (useful while the person is still typing).
3. A French-language phonetic match.
4. A generic phonetic match.

In practice this means a short or slightly misspelled search term can still surface the right record — but it also means a search can occasionally return a phonetically-similar record that isn't the one you meant (e.g. searching "Dupont" can also surface "Dupond").

Example:

curl -G "https://your-standalone-url/api/searchRecords" \
  --data-urlencode "search=Dupont" \
  --data-urlencode "recordType=Contact" \
  -H "Authorization: Basic <base64 value>"

POST /api/lookupRecords

Body: a JSON object of field/value pairs to match on, plus pid or recordType (either in the body or as query parameters), for example:

{
  "pid": 12,
  "LastName": "Dupont",
  "Email": "a@b.com"
}

Example:

curl -X POST "https://your-standalone-url/api/lookupRecords" \
  -H "Authorization: Basic <base64 value>" \
  -H "Content-Type: application/json" \
  -d '{"recordType": "Contact", "LastName": "Dupont", "Email": "a@b.com"}'

Returns a JSON array of every candidate record your RuleSet's matching rules consider a possible match — there's no limit on the number of results and no ranking/score per record. Treat this as a shortlist to narrow down yourself, not a final answer.

POST /api/lookupGolden — real-time duplicate check

Same request body as lookupRecords. This is the only endpoint that applies full scoring — it reuses the same matching algorithms and the Threshold settings configured on your RuleSet's Matching tab.

curl -X POST "https://your-standalone-url/api/lookupGolden" \
  -H "Authorization: Basic <base64 value>" \
  -H "Content-Type: application/json" \
  -d '{"recordType": "Contact", "LastName": "Dupont", "Email": "a@b.com"}'

Response, if a match is found:

{
  "certainty": 0.92,
  "matched_by": "Name + Email",
  "record": { "LastName": "Dupont", "Email": "a@b.com", ... }
}

• certainty — a score from 0 to 1 (1 = exact match), derived from the matching rule's distance score.
• matched_by — the name of the matching rule that produced the best score.
• record — the full indexed record. If your Index Records process has a Parent Id field configured, this is the parent of the matched record rather than the match itself.

If nothing matches closely enough to satisfy any rule's Threshold, the response is an empty object {} — treat that as "no duplicate found."

Keeping the index up to date

There's no incremental indexing — every time the Index Records process runs, it fully rebuilds its index from scratch. To keep results current:

• Re-run the process manually, or schedule it (see Schedule a process in DQE One Standalone) — the shortest available frequency is every 15 minutes.
• Changing the RuleSet's matching rules takes effect immediately on these 4 endpoints without needing to re-run anything — but this only affects how future queries are scored, not the indexed data itself.

Error handling

Almost every error — a missing pid/recordType, an unknown recordType, a malformed request body — comes back as a normal HTTP 200 response with {"status":"error","error":"..."} in the body. The only case that returns a different HTTP status is authentication failure (401). Always check the response body, not just the HTTP status code.

Limits

• searchRecords/searchGolden return at most 50 results, with no pagination — narrow your search term if you need to see more.
• There's no built-in rate limiting on any of these 4 endpoints. If you're calling them from a high-traffic integration (for example, a public-facing search box), add your own throttling on your side rather than relying on DQE One Standalone to protect itself.

Related articles

• Create and launch a process in DQE One Standalone
• Connect a data source in DQE One Standalone
• Configure a RuleSet in DQE One Standalone
• Schedule a process in DQE One Standalone