Wolken
The Wolken source ingests knowledge-base articles from a Wolken ServiceDesk instance. Each article becomes a record in the pipeline — its contents are uploaded to a new agent session for processing. Articles are filtered by the lifecycle, validation, and audience-level filters you configure, and each article's audience attributes are carried as document metadata for attribute-based filtering.
Authentication
Before you create the pipeline, obtain the Wolken API endpoint, tenant domain, OAuth client ID, service account, auth code, and refresh token from your Wolken administrator or Wolken support. There is no Vectara-hosted flow for issuing these credentials.
Despite its name, auth_code is not a browser OAuth authorization code. It is
sent verbatim as the Authorization header on the token request, so include any
scheme prefix Wolken issues it with (typically Basic <base64>).
Configuration
The connector reads Wolken's data API. It requires credentials with read access to the knowledge-base listing and article-detail endpoints. Incremental sync additionally requires the listing to support update-time filters. Which filters the listing accepts, and the specific status, validation, and level IDs, vary by Wolken deployment.
SOURCE FIELD (WOLKEN)
Code example with json syntax.1
Fields
| Field | Required | Description |
|---|---|---|
type | Yes | wolken_kb. |
api_endpoint | Yes | Base URL of the Wolken API (e.g. https://example-api.wolkenservicedesk.com). |
domain | Yes | The Wolken tenant name issued with your credentials, not a hostname. For example example, not example.wolkenservicedesk.com. |
client_id | Yes | Wolken OAuth client ID. |
service_account | Yes | Wolken service account the data API calls run as. |
auth_code | Yes | The auth code Wolken issues for the instance, used with refresh_token to obtain access tokens. Sent verbatim as the Authorization header on the token request, typically in Basic <base64> form. Encrypted at rest and never returned in responses. |
refresh_token | Yes | Long-lived refresh token exchanged for access tokens. Encrypted at rest and never returned in responses. |
status_id | No | Lifecycle status to filter articles by. If unset, articles of every lifecycle status are ingested. Status IDs are specific to your deployment. |
validation_status_id | No | Validation status to filter articles by. If unset, articles of every validation status are ingested. Validation status IDs are specific to your deployment. |
level_id | No | Audience level to filter articles by. If unset, articles of every audience level are ingested. Level IDs are specific to your deployment. |
update_upper_bound_operator | No | Operator for the incremental-sync upper bound when filtering by last-updated time. lt is strict less-than; lte is less-than-or-equal. Defaults to lte. |
article_url_template | No | Template for each article's public URL. The {article_number} placeholder is replaced with the article number. When omitted, the URL returned by the Wolken listing is used. |
How records are fetched
Each run enumerates the knowledge-base listing, applying the status_id,
validation_status_id, and level_id filters you configured. Each article that
passes the filters becomes one record. Article contents are read from the
article-detail endpoint and composed into a single HTML document from the
labeled sections the response carries.
Articles are enumerated with offset pagination. An article edited or archived while a run is in flight can shift position between pages and be skipped until its next edit or a full refresh. Wolken offers no change-token alternative.
Source metadata
Each record carries source metadata that the connector resolves at fetch time.
system_metadata:
| Key | Description |
|---|---|
title | The article title. |
status_name | The article's lifecycle status name. |
url | The article's public URL, from article_url_template or the listing. Absent when neither provides one. |
created_time | The article's created time, as reported by Wolken. |
updated_time | The article's last-updated time, as reported by Wolken. |
user_metadata carries the article's audience attributes for attribute-based
filtering, populated only when present in the response: article_number,
status_name, level_name, article_type, review_date, category_names,
software_release, validation_status, published_date, support_product,
and support_product_id. status_name is emitted in both buckets: in
system_metadata as the article's lifecycle status, and here as a filterable
audience attribute.
acl_metadata reports org_wide_access as READER. Wolken articles carry no
per-principal grants — access is audience-level and already enforced by the
listing filters, so the principal buckets of the source-independent
ACL metadata shape are left
null.
Incremental sync
When sync_mode is incremental (the default), the pipeline tracks a watermark
based on each article's last-updated time. See
Sync mode.
On the next run, only articles updated since the stored watermark are reprocessed. The next run's inclusive lower bound re-covers the boundary, and per-record deduplication absorbs the overlap.
Deletes are not propagated. An article the connector can no longer retrieve (or that falls out of the configured filters) stops appearing in new runs. The pipeline emits no delete signal, so anything a previous run already produced downstream — for example, a document indexed into a corpus — is left in place.