REST API Reference

Name: Viglet Turing
Author: Viglet

Viglet Dumont exposes a REST API for triggering indexing operations, monitoring progress, managing sources, and configuring indexing rules. All endpoints use JSON and support CORS.

Connector API

Base path: /api/v2/connector

Health Check

GET /api/v2/connector/status

Returns {"status": "ok"} if the service is running.

Index All Content

GET /api/v2/connector/index/{name}/all

Triggers a full indexing operation for all content in the specified source.

Parameter	Location	Description
`name`	Path	Source name

Response: {"status": "sent"}

Status	Meaning
`200`	The run started.
`404`	No connector plugin manages a source with this name: `{"status": "unknown source", "reason": "..."}`. Create the source first.
`409`	A run for this source is already in progress: `{"status": "already running"}`.

Index Specific Content

POST /api/v2/connector/index/{name}

Indexes specific documents by their IDs.

Parameter	Location	Description
`name`	Path	Source name
(body)	JSON	Array of content IDs: `["id-1", "id-2"]`

Response: {"status": "sent"}

Reindex All Content

GET /api/v2/connector/reindex/{name}/all

Deletes the existing index and reindexes all content from the source.

Parameter	Location	Description
`name`	Path	Source name

Response: {"status": "sent"}. Answers 404 and 409 exactly as Index All Content does.

Reindex Specific Content

GET /api/v2/connector/reindex/{name}

Deletes and reindexes specific documents.

Parameter	Location	Description
`name`	Path	Source name
(body)	JSON	Array of content IDs

Response: {"status": "sent"}

Validate Source

GET /api/v2/connector/validate/{source}

Validates content differences between the source and the search index. Used by the Viglet Turing Double Check feature.

Parameter	Location	Description
`source`	Path	Source name

Response: DumConnectorValidateDifference: lists missing and extra documents.

Orphan Reports

Base path: /api/v2/connector/orphans

An orphan is a document the search index still holds after it left the source. The content audit never deletes one, because an orphan is only an orphan if the discovery pass that failed to mention it was complete: a gateway that timed out, or a listing that paginated short, makes every unlisted id look like a ghost. Deleting on that evidence would take live content out of the index.

So each audit pass writes the ids it found into a dated report and stops there. You read the report, decide whether it describes content that genuinely went away, and then apply or discard it. Applying goes through the connector's own de-index path, so the indexing ledger and the search index stay in step.

The console has an Orphan Reports screen over these endpoints, which is the easier way to do the review: it shows each report's id count against how many documents the site indexes, so a report naming most of the index reads as a failed discovery pass rather than a cleanup. The endpoints below are for scripting it.

A report is per source and per site, and only the newest one stands: a later pass supersedes the report it replaces, and a pass that finds no orphan retracts it. A report also expires (see dumont.audit.index.orphanTtl), because applying evidence that a reindex has since overtaken would delete live documents.

To produce a report on demand rather than waiting for the cron, run the audit:

GET /api/v2/connector/audit/{source}

List Reports

GET /api/v2/connector/orphans
GET /api/v2/connector/orphans?source={source}
GET /api/v2/connector/orphans/{id}

Newest evidence first. Each report carries its source, provider, site, the objectIds it found, discoveredAt, expiresAt, whether it has already expired, and a status of pending, applied or discarded.

Apply a Report

POST /api/v2/connector/orphans/{id}/apply

De-indexes every id in the report from its site and drops the matching ledger rows, then closes the report. Response: { "status": "applied", "deindexed": 12 }.

Status	Meaning
`200`	Applied: `deindexed` says how many delete jobs were queued
`404`	No report carries that id, or a later pass superseded it
`409`	Already applied or discarded: a decision is made once
`410`	The evidence aged past `dumont.audit.index.orphanTtl`; re-run the audit

Discard a Report

POST /api/v2/connector/orphans/{id}/discard

Closes the report without deleting anything: the right answer when the source was unreachable during the pass that produced it. Response: { "status": "discarded" }.

Logging API

Base path: /api/v2/connector/logging

The indexing log records every status a document passes through: prepared, sent to the queue, delivered to the search engine. Each row names the document, the source that produced it and the transaction id of the run it belonged to, so you can ask what one source did or replay a single run end to end.

It needs a store: see Indexing Log configuration. With no engine configured the endpoints below answer with an empty page.

Is It On?

GET /api/v2/connector/logging/status

Response: { "engine": "mongodb", "configured": true, "enabled": true, "writing": true }.

The three flags answer different questions, and the ways a log goes wrong are exactly where they disagree:

Field	Answers	Read from
`configured`	Is an engine named and switched on?	`dumont.logging.*` properties
`enabled`	Does that engine actually answer?	a ping, at request time
`writing`	Is an appender attached that would accept a row?	the live Logback configuration

Read them together:

State	Means	Fix
`configured: false`	The log is not part of this deployment	Nothing, unless you wanted it
`enabled: false`	The store is named but unreachable	Check the URI and the credentials
`writing: false`	The store answers, but nothing writes to it	Remove any `logging.config` override; the engine derives it (before 2026.3.7 the Docker image pinned one)
all three `true`	The log is on, reachable and being written	n/a

writing exists because the first two describe only the reader: this endpoint's own client. Rows are written by a Logback appender, and since 2026.3.7 the profile that declares it is derived from dumont.logging.engine, so the two cannot drift apart unless you override logging.config yourself. Gate a screen on enabled, and use writing to tell an empty history apart from one that nothing is filling.

note

writing is absent on connectors older than 2026.3.7. Absent is not false: those versions cannot answer the question at all.

Read the Log

GET /api/v2/connector/logging/indexing

Parameter	Description
`source`	Everything one source did
`transactionId`	Everything that happened in one run
`contentId`	One document's whole history
`status`	`PREPARE_INDEX`, `SENT_TO_QUEUE`, `RECEIVED_AND_SENT_TO_TURING`, `DEINDEXED`, …
`resultStatus`	`SUCCESS` or `ERROR`
`url`	Case-insensitive substring match on the document URL
`dateFrom`, `dateTo`	`YYYY-MM-DD`, inclusive
`page`, `pageSize`	Default `0` and `100`
`sort`	`desc` (default) or `asc`, by date

Filters combine, and any you omit is simply not applied. Response: { content, page, pageSize, totalElements, totalPages, unreadable }.

unreadable counts rows the engine skipped because it could not read them. It is normally 0. On a Redis log carrying rows written before 2026.3.6 it will not be: those rows are not valid JSON, and they are skipped one at a time rather than failing the query. They clear as the list rolls past its maxEntries, or immediately if you delete the key.

Rows written by a connector older than 2026.3.6 carry no source or transaction id. They still appear in an unfiltered listing (an unattributed row is a fact about an old message, not something to hide), but they cannot answer a query that names a source.

note

Both engines honour every filter above. The Redis engine applies them in memory after reading the whole list, so it slows as the log grows: pick MongoDB when you intend to query rather than tail.

A store that is down is not an empty log

If the endpoint cannot reach its store it answers 503 Service Unavailable, naming the engine, never 200 with an empty page. The distinction matters: an empty page means the connector logged nothing, a 503 means the log cannot be read and the connector may well have indexed everything. Earlier releases returned the empty page for both, so an outage read as an idle connector.

Source Inference API

Base path: /api/v2/connector/source/infer

Proposes a structured source from a URL, previews what indexing it would produce, and indexes the draft a human has confirmed. Nothing here publishes on its own: infer and preview write nothing, and infer/index runs only on a draft you send back.

Propose a Source

POST /api/v2/connector/source/infer

Fetches a sample of the URL, classifies its shape (SITEMAP, HTML_LISTING, TABULAR_LISTING, or UNKNOWN) and proposes an editable draft: the strategy configuration plus a field manifest with a type per field.

Body: { "url": "https://example.com/courses" }

Response: DumSourceDraft: the shape, the strategy configuration, and the inferred fields.

It proposes structure (selectors and field types), never content, and returns UNKNOWN rather than guessing when the sample gives it nothing to go on.

Dry-Run Preview

POST /api/v2/connector/source/infer/preview?sampleSize=20

Extracts a bounded sample through the same discover → extract → enrich path a real run uses, and reports what would happen: per-field coverage, records that would be skipped for a missing mandatory field, and a diff against the last full index (added, changed, removed, and fields that would go newly empty), plus a schema diff. Writes nothing.

Parameter	Location	Default	Description
`sampleSize`	Query	`20`	Records to extract for the preview

Body: the confirmed draft, as sent to infer/index below.

Response: { success, preview, message }.

On a source's first onboarding there is no baseline, so everything reads as added.

Index a Confirmed Draft

POST /api/v2/connector/source/infer/index

Materialises the draft into a live structured source and indexes it. This is the only endpoint of the three that writes, and it acts on the draft in the request body: a proposal is never indexed without being sent back.

Body: { "url", "sourceName", "siteNames": [...], "locale", "draft" }

Response: { success, source, message }.

Monitoring API

Base path: /api/v2/connector/monitoring

Get Indexing Status

GET /api/v2/connector/monitoring/index/{source}

Returns indexing status records for a specific source. Returns 404 if no records found.

Get All Monitoring Data

GET /api/v2/connector/monitoring/indexing

Returns all indexing monitoring data across all sources.

Get Monitoring by Source

GET /api/v2/connector/monitoring/indexing/{source}

Returns monitoring data filtered by source name.

Search Monitoring Records

POST /api/v2/connector/monitoring/indexing/_search

Searches indexing monitoring records with pagination and filters.

Request body:

{
  "source": "WKND",
  "status": "INDEXED",
  "page": 0,
  "size": 20
}

Get Monitoring by Content IDs

POST /api/v2/connector/monitoring/indexing

Request body: Array of content IDs.

Indexing Statistics

GET /api/v2/connector/monitoring/indexing/stats
GET /api/v2/connector/monitoring/indexing/stats/{source}

Returns indexing operation statistics (start time, document count, duration, throughput). Returns 404 if no stats found.

System Information API

GET /api/v2/connector/system-info

Returns runtime system information consumed by the Turing Integration → System Information page:

Application name and version
Java version, vendor, and JVM details
Operating system name and version
Physical memory (total, used, free)
JVM heap memory (total, used, free)
Disk space (total, used, free)

Indexing Rules API

Base path: /api/v2/connector/indexing-rule

CRUD operations for managing regex-based indexing rules that filter content during extraction.

List All Rules

GET /api/v2/connector/indexing-rule

List Rules by Source

GET /api/v2/connector/indexing-rule/source/{source}

Get Rule by ID

GET /api/v2/connector/indexing-rule/{id}

Create Rule

POST /api/v2/connector/indexing-rule

Request body:

{
  "name": "Exclude error pages",
  "source": "WKND",
  "attribute": "template",
  "ruleType": "IGNORE",
  "values": ["error-page", "redirect"]
}

Update Rule

PUT /api/v2/connector/indexing-rule/{id}

Request body: Same as create.

Delete Rule

DELETE /api/v2/connector/indexing-rule/{id}

Response: true if deleted, false if not found.

Get Empty Structure

GET /api/v2/connector/indexing-rule/structure

Returns an empty model for reference.

AEM Plugin API

Base path: /api/v2/aem

These endpoints are available when the AEM plugin JAR is loaded via -Dloader.path.

Health Check

GET /api/v2/aem/status

Returns {"status": "ok"}.

Index AEM Paths

POST /api/v2/aem/index/{source}

Triggers indexing for specific AEM content paths. Includes built-in deduplication, repeated requests for the same paths within 30 seconds are ignored.

Parameter	Location	Description
`source`	Path	AEM source name (e.g., `WKND`)
(body)	JSON	`DumAemPathList` object

Request body:

{
  "paths": ["/content/wknd/us/en/about"],
  "event": "INDEXING",
  "recursive": false,
  "attribute": "ID"
}

Field	Type	Default	Description
`paths`	string[]	(required)	AEM content paths
`event`	string	`INDEXING`	`INDEXING`, `DEINDEXING`, `PUBLISHING`, or `UNPUBLISHING`
`recursive`	boolean	`false`	Traverse child nodes
`attribute`	string	`ID`	`ID` (path-based) or `URL` (URL-based)

Response: {"status": "sent"}

AEM Source Management

CRUD operations for AEM source configurations.

List All Sources

GET /api/v2/aem/source

Get Source by ID

GET /api/v2/aem/source/{id}

Create Source

POST /api/v2/aem/source

Request body: Full DumAemSource JSON (see Extending the AEM Connector, Configuration JSON).

Update Source

PUT /api/v2/aem/source/{id}

Returns 400 if ID mismatch, 404 if not found.

Delete Source

DELETE /api/v2/aem/source/{id}

Index All Content for Source

GET /api/v2/aem/source/{id}/indexAll

Triggers an asynchronous full indexing operation for the specified AEM source.

Get Empty Structure

GET /api/v2/aem/source/structure

Returns an empty AEM source model for reference.

Page	Description
AEM Connector	AEM indexing flow, event listeners, and manual triggering
Connectors Overview	All connectors and how they're managed
Turing: Integration	Turing admin console for managing connectors

Connector API​

Health Check​

Index All Content​

Index Specific Content​

Reindex All Content​

Reindex Specific Content​

Validate Source​

Orphan Reports​

List Reports​

Apply a Report​

Discard a Report​

Logging API​

Is It On?​

Read the Log​

Source Inference API​

Propose a Source​

Dry-Run Preview​

Index a Confirmed Draft​

Monitoring API​

Get Indexing Status​

Get All Monitoring Data​

Get Monitoring by Source​

Search Monitoring Records​

Get Monitoring by Content IDs​

Indexing Statistics​

System Information API​

Indexing Rules API​

List All Rules​

List Rules by Source​

Get Rule by ID​

Create Rule​

Update Rule​

Delete Rule​

Get Empty Structure​

AEM Plugin API​

Health Check​

Index AEM Paths​

AEM Source Management​

List All Sources​

Get Source by ID​

Create Source​

Update Source​

Delete Source​

Index All Content for Source​

Get Empty Structure​

Related Pages​

Connector API

Health Check

Index All Content

Index Specific Content

Reindex All Content

Reindex Specific Content

Validate Source

Orphan Reports

List Reports

Apply a Report

Discard a Report

Logging API

Is It On?

Read the Log

Source Inference API

Propose a Source

Dry-Run Preview

Index a Confirmed Draft

Monitoring API

Get Indexing Status

Get All Monitoring Data

Get Monitoring by Source

Search Monitoring Records

Get Monitoring by Content IDs

Indexing Statistics

System Information API

Indexing Rules API

List All Rules

List Rules by Source

Get Rule by ID

Create Rule

Update Rule

Delete Rule

Get Empty Structure

AEM Plugin API

Health Check

Index AEM Paths

AEM Source Management

List All Sources

Get Source by ID

Create Source

Update Source

Delete Source

Index All Content for Source

Get Empty Structure

Related Pages