The DQE One Standalone API lets you control your self-hosted DQE One Standalone server remotely: upload files, connect data sources, create and run data-quality processes, follow their runs and manage RuleSets — everything you can do in the web interface to automate batch processing.
Authentication
Every endpoint uses HTTP Basic authentication:
your DQE One email as the username and your
API token as the password (Authorization: Basic base64(email:api_token);
with curl, -u "email:token"). No session, Bearer
token or OAuth is accepted on these routes.
- Sign in to your DQE One Standalone web interface.
- Open My Account and the API Token section, then generate the token.
- Use it as the Basic password. Regenerating it invalidates the previous one.
Conventions
| Topic | Behaviour |
|---|---|
| Base URL |
https://{DOMAIN}/api/... — DQE One
Standalone is self-hosted, so
{DOMAIN} is your own server.
|
| Ownership | Everything is scoped to the authenticated user. Another user's id answers 404, never 403. |
| Success |
{"status":"success", ...}. Lists
are bare JSON arrays. Creation
endpoints answer 201, including
updateProcess.
|
| Errors |
{"status":"error","error":"<message>"}
in English. Exceptions are flagged on each endpoint
(for example runProcess uses message,
and RuleSet import returns error
as a list).
|
| 401 |
{"status":"error","error":"Unauthorized"}
for a missing, wrong or unknown credential. A
malformed header (not base64, or without
:) can produce an unformatted 500
instead.
|
| Methods |
A wrong method answers 405.
runProcess and deleteProcess are GET requests that change data.
|
| Asynchronous work |
runProcess only queues the run.
Poll getRuns. Jobs run one at a
time per user.
|
| Unformatted 500 |
A few inputs (a non-numeric id,
a process that never ran) raise a plain server
error instead of JSON. Validate ids on your side.
|
| Limits | No rate limiting, no pagination, no explicit upload size limit, tokens never expire. CORS is open to any origin (authority comes from the Authorization header). |
| Interactive docs |
Your server also serves ReDoc at /doc/
and Swagger UI at /doc/swagger/.
They are not fully accurate
(key names, status codes, array vs object responses):
prefer this documentation and the OpenAPI file
above.
|
API map
| Article | Endpoints |
|---|---|
| Files |
addFile, listFiles,
getProcessResult, deleteFile
|
| Credentials |
createCredential, listCredentials,
getCredential, deleteCredential
|
| Processes |
createProcess, updateProcess,
listProcesses, getProcess,
runProcess, deleteProcess
|
| Runs & results |
getRuns
|
| RuleSets |
listRulesets, getRuleset,
exportRulesets, importRuleset
|
| MCP server |
The same operations for AI assistants (Claude
and other MCP clients): JSON-RPC at /mcp.
|
Looking for real-time duplicate lookup? That is a separate API: Use the Lookup API in DQE One Standalone.
End-to-end example
This complete flow needs nothing but a CSV file. For a database
or CRM source, create a credential first (Credentials)
and use "source":"postgres",
"object":"<table>",
"credential":<id> instead of file.
Clean-up order matters: delete the process
first (once its run is Finished or Failed),
then the credential, then the file; each is refused with
423 while something still uses it.
Known limitations
-
find_and_replace,formatandauditprocesses cannot be created reliably through the API, and Snowflake processes always fail validation: use the web interface for these. -
updateProcesscannot set a boolean back tofalseand resets the fields you do not send. -
There is no endpoint to cancel a run, and
getProcessResultreturns only the key and synchronised columns. - Dynamics and Snowflake credentials need a browser login to complete.
These describe the current behaviour of the product, not planned changes.
See also
Related to