The DQE One backend for Salesforce exposes APIs used by the Salesforce package to trigger and manage backend processes — configuring data sources, running merge and audit jobs, and managing the package's embedded custom UI sessions.
The DQE One API is different from the other DQE APIs documented in this Help Center: it is not a public lookup or validation service called directly by your own applications. It is the backend used internally by the DQE One package for Salesforce — the package calls it (and a subset of endpoints are, in turn, called by DQE-hosted services acting on the package's behalf) to retrieve data-cleansing configuration, launch backend jobs, and manage the package's custom UI. This article introduces the API as a whole; each other article in this family documents one functional area in detail.
Authentication model
The DQE One API defines two separate security schemes in its OpenAPI specification. Most endpoints require one of the two; a few — like the health check below — require neither.
| Scheme | How it works | Typically used for |
|---|---|---|
| DQE-Authorization | An API key passed in a custom HTTP header named DQE-Authorization.
OpenAPI type: apiKey, in: header
|
Most backend endpoints called by the Salesforce package — for example issuing a process token or managing data configuration. |
| bearerAuth | A standard Bearer JSON Web Token passed in the Authorization header, e.g. Authorization: Bearer {JWT}.
OpenAPI type: http, scheme: bearer, bearerFormat: JWT
|
A smaller set of custom UI management endpoints. |
DQE-Authorization key or a bearer JWT is obtained outside of the token/subscription flows described in the Authentication & Session article has not been documented by DQE engineering yet — confirm with the team before publishing if anything here needs correcting.Each endpoint declares its own requirement individually. See the Authentication & Session article for the three endpoints that issue or consume these credentials, and each endpoint-specific article for what that particular endpoint expects.
Articles in this family
The DQE One API is documented across five articles:
| Article | Covers |
|---|---|
| Introduction | This page — overview, authentication model, and the GET /echo health check. |
| Authentication & Session |
POST /getOAuthTokenForProcess, POST /subscribe, POST /customUI/createTokenSession. |
| Data Configuration |
POST /getDCMetadata, POST /getFusionField, POST /createFusionLookup. |
| Jobs & Audits |
POST /newJob, POST /launchAudit, POST /previewDataPrep. |
| Custom UI Management |
POST /customUI/resetRules, POST /customUI/importRules. |
/lanchAudit path (sic — appears to be a duplicate or misspelling of /launchAudit; it has no operationId and declares no security scheme) and a /newJob request body that is defined as a $ref pointing at /lanchAudit's own request body rather than at a shared component schema. Neither oddity is addressed in this introduction — flag both with DQE engineering before documenting /newJob and /launchAudit.Health check — GET /echo
Request
A simple availability check used to confirm the backend is reachable. It takes no parameters and requires no authentication.
{DOMAIN} is the backend domain configured for your DQE One package instance. The OpenAPI specification models this as a configurable domain server variable rather than a single fixed host.
Response
Returns a fixed JSON object confirming the service is up.
| Key | Description | Type |
|---|---|---|
| status | Fixed value confirming the backend is reachable. | String |
Example response
Errors
The source specification does not define any error responses for this endpoint.
Test the API
Click the button below to test this endpoint live in your browser.
Open console
See also
Related to