Skip to main content

Overview

The Velt Node SDK exposes two independent backends:
BackendNamespaceUse case
Self-hostingsdk.selfHosting.*Store Velt data in your own MongoDB + AWS S3
REST APIsdk.api.*Call Velt’s REST APIs directly from your backend
Self-hosting backend (sdk.selfHosting.*) simplifies backend implementation by 90%. Instead of writing custom database queries and storage logic, you:
  1. Pass your DB and storage configs to the SDK
  2. Call the relevant SDK method with the raw request payload
  3. Return the resulting response directly to the client
REST API backend (sdk.api.*) provides parity with Velt’s REST APIs. 18 services, fully-typed TypeScript request objects, and raw Velt API responses. API calls do not read or write MongoDB or AWS S3.
In @veltdev/node@1.0.7, VeltSDK.initialize still validates the top-level database config. Pass your database config during initialization even when you only call sdk.api.*; the REST API methods themselves do not use it.

Installation

For self-hosting, also install the optional peer dependencies you plan to use:

Requirements

  • Node.js 18+
  • TypeScript 5.x (optional — JavaScript is fully supported)
  • MongoDB 6+ (Percona Server or MongoDB Atlas) for self-hosting
  • mongodb ^6, @aws-sdk/client-s3 ^3, and jose ^5 (for verifyToken) as optional peer dependencies

Quick Start

Initialize the SDK

Self-hosting initialization (MongoDB + optional AWS):

Shutdown

Call await sdk.close() when your process exits to release the database connection pool.

Configuration

Environment Variables

VariableConfig key equivalentPurpose
VELT_API_KEYapiKeyVelt API key for authenticating REST API calls
VELT_AUTH_TOKENauthTokenVelt auth token for authenticating REST API calls
VELT_WORKSPACE_IDDefault workspace ID for workspace-scoped operations
VELT_WORKSPACE_AUTH_TOKENAuth token scoped to a specific workspace
AWS_ACCESS_KEY_IDAWS access key for S3 attachments
AWS_SECRET_ACCESS_KEYAWS secret key for S3 attachments
AWS_REGIONAWS region for S3
AWS_S3_BUCKET_NAMES3 bucket name for attachments
AWS_S3_ENDPOINT_URLCustom S3 endpoint (e.g., for MinIO)

Self-Hosting Configuration

Configure MongoDB connection for storing comments, reactions, and user data.

Self-Hosting Backend

Each self-hosting service is loaded asynchronously on first access via await sdk.selfHosting.getXxx(). The service is cached after the first call. The token service is the exception — it is available as a direct synchronous property via sdk.selfHosting.token.

Comments

Access via await sdk.selfHosting.getComments().

getComments

Response

saveComments

Response
Resolver contract: When saveComments runs as a save-resolver handler, the inbound event may be a ResolverActions or a CommentResolverSaveEvent member (or a raw string), and the request may include targetComment?: PartialComment — the comment the action occurred on (request context only, never persisted). See SaveCommentResolverRequest.

deleteComment

Response

Reactions

Access via await sdk.selfHosting.getReactions().

getReactions

Response

saveReactions

Response

deleteReaction

Response

Attachments

Access via await sdk.selfHosting.getAttachments().

getAttachment

  • Fetches an attachment record by organization and attachment ID.
  • Params: positional — organizationId (string), attachmentId (number)
  • Returns: VeltSelfHostingResponse
Response

saveAttachment

Response

deleteAttachment

Response

Users

Access via await sdk.selfHosting.getUsers().

getUsers

Response

Recorder

Access via await sdk.selfHosting.getRecorder().

getRecorderAnnotations

Response

saveRecorderAnnotation

Response

deleteRecorderAnnotation

Response

Notifications

Access via await sdk.selfHosting.getNotifications().

getNotifications

Response

saveNotifications

Response

deleteNotification

Response

Activities

Access via await sdk.selfHosting.getActivities().

getActivities

Response

saveActivities

Response

Token

Access via the synchronous sdk.selfHosting.token property (no await).

getToken

  • Generates a Velt auth token for a user.
  • Params: positional — organizationId (string), userId (string), email (string, optional), isAdmin (boolean, optional)
  • Returns: VeltSelfHostingResponse
Note: getToken takes positional arguments — not a request object.
Response

verifyToken

sdk.selfHosting.verifyToken verifies the auth credential the Velt frontend forwards to endpoint-based resolvers. It is database-free (it does not open or query MongoDB), fail-closed (every error path returns { verified: false }, never throws), and authentication only (claims are returned verbatim; it makes no authorization decision).
In @veltdev/node@1.0.7, VeltSDK.initialize still validates the top-level database config before you can access sdk.selfHosting. Include your self-hosting database config when initializing the SDK. The verifyToken method itself remains database-free after initialization.
Optional dependency: npm install jose@^5 (optional peerDependency, pinned ^5 for Node 18 — jose v6 needs the WebCrypto global absent on Node 18). If jose is missing and the built-in JWT path is used, verifyToken returns { verified: false, errorCode: 'DEPENDENCY_MISSING' }. The custom verify callback path needs no dependency.

Configuration

Configure resolverAuth on VeltSDK.initialize. Provide the built-in jwt path, a custom verify callback, or both. When both are set, the custom callback takes priority.

Usage

Call verifyToken from your endpoint-based resolver route, then branch on result.verified.
Per-call options override the configured resolverAuth (the jwt block is deep-merged):
Signature
  • Params: inline options object with headers, token, and per-call ResolverAuthConfig overrides. This parameter shape is not exported as a named SDK type.
  • Returns: VerifyTokenResult
The verification logic is implemented by the ResolverAuthService class (also exported from @veltdev/node) for advanced callers who need to construct it directly; sdk.selfHosting.verifyToken is the standard entry point.

Error codes

On failure, result.errorCode is one of the ResolverAuthErrorCode values (also exported as the readonly string[] const RESOLVER_AUTH_ERROR_CODES).
CodeWhen
NOT_CONFIGUREDNeither jwt nor a verify callback is configured.
MISSING_TOKENNo token found in headers, or wrong scheme.
EXPIREDJWT exp claim has passed (beyond leeway).
INVALID_SIGNATURESignature verification failed, or malformed token.
CLAIM_MISMATCHConfigured issuer/audience wrong or absent; or a required claim is missing.
ALGORITHM_NOT_ALLOWEDalg=none; algorithm outside the allowlist; mixed symmetric+asymmetric allowlist; missing allowlist.
KEY_RESOLUTION_FAILEDNo usable key; JWKS URL is not HTTPS; JWKS fetch failed or returned non-2xx; redirect downgrade detected.
DEPENDENCY_MISSINGBuilt-in JWT path used but jose is not installed.
VERIFICATION_FAILEDCustom callback threw or returned falsy; unexpected internal error (fail-closed catch-all).

Security guarantees

  • alg=none is always rejected, even if present in the allowlist.
  • Mixed symmetric+asymmetric allowlists are refused (prevents HS/RS confusion).
  • A PEM placed in jwt.secret is refused.
  • JWKS is fetched only over HTTPS — http is rejected pre-fetch, and a redirect downgrade is rejected.
  • JWKS responses are cached per URL with a 5-minute TTL (not per kid).
  • The token-header alg is checked against the allowlist before any JWKS fetch.
  • The error field is generic and code-based — it never contains the token or secret.

REST API Backend

The sdk.api.* namespace gives you parity with Velt’s REST APIs across 18 services. Each method takes a fully-typed TypeScript request object and returns the raw Velt API response. API methods need apiKey and authToken and do not use MongoDB or AWS S3, although @veltdev/node@1.0.7 still validates the top-level database config at initialization. Every sdk.api.* method requires an organizationId in its request payload. Velt enforces data isolation per-organization server-side.

Field Allowlist

The REST add/update methods on activities, commentAnnotations, and notifications accept an optional second argument, FieldFilterOptions. Pass { filterUnknownFields: true } to narrow the request to exactly the fields the corresponding Velt backend endpoint accepts. See the note at the top of each service section for the behavior summary; the per-endpoint field lists are below.

Exported filter utilities

The field-allowlist module is exported from @veltdev/node so advanced callers can reuse the same logic.
  • pickKnownFields(data, keys) — keeps only own-enumerable keys present in keys; values kept by reference (no recursion); non-object/array/null inputs returned unchanged.
  • filterRequest(request, spec) — applies a FilterSpec recursively; never mutates input; fail-open (returns the original request on any error).
  • Eight per-method specs are exported: ADD_ACTIVITIES_SPEC, UPDATE_ACTIVITIES_SPEC, ADD_COMMENT_ANNOTATIONS_SPEC, UPDATE_COMMENT_ANNOTATIONS_SPEC, ADD_COMMENTS_SPEC, UPDATE_COMMENTS_SPEC, ADD_NOTIFICATIONS_SPEC, UPDATE_NOTIFICATIONS_SPEC.

Allowlisted fields per endpoint

When filterUnknownFields: true, only these keys survive (unknown keys dropped):
Spec (endpoint)Top-level keysNested item filtering
ADD_ACTIVITIES_SPEC (/v2/activities/add)organizationId, documentId, activitiesactivities[]: id, featureType, actionType, actionUser, targetEntityId, isActivityResolverUsed, targetSubEntityId, changes, entityData, entityTargetData, displayMessageTemplate, displayMessageTemplateData, actionIcon
UPDATE_ACTIVITIES_SPEC (/v2/activities/update)organizationId, activitiesactivities[]: id, changes, entityData, entityTargetData, displayMessageTemplate, displayMessageTemplateData, actionIcon
ADD_COMMENT_ANNOTATIONS_SPEC (/v2/commentannotations/add)organizationId, documentId, commentAnnotations, verifyUserPermissions, createDocument, createOrganizationcommentAnnotations[]: location, annotationId, targetElement, commentData, comments, status, commentType, type, assignedTo, priority, context, visibility, lastUpdated, createdAt, pageInfo, isPageAnnotation, positionX, positionY, screenWidth, screenHeight, screenScrollHeight, screenScrollTop — its comments[]/commentData[] use the annotation comment-data set (below)
UPDATE_COMMENT_ANNOTATIONS_SPEC (/v2/commentannotations/update)organizationId, documentId, annotationIds, locationIds, userIds, updateUsers, updatedDataupdatedData: location, targetElement, from, status, assignedTo, priority, context, visibility, createdAt, lastUpdated
ADD_COMMENTS_SPEC (/v2/commentannotations/comments/add)organizationId, documentId, annotationId, commentData, comments, verifyUserPermissions, createDocument, createOrganizationcommentData[]/comments[]: comment-data set (below)
UPDATE_COMMENTS_SPEC (/v2/commentannotations/comments/update)organizationId, documentId, annotationId, commentIds, userIds, updatedDataupdatedData: commentText, commentHtml, from, createdAt, taggedUserContacts, isCommentResolverUsed, isCommentTextAvailable, lastUpdated, context, attachments
ADD_NOTIFICATIONS_SPEC (/v2/notifications/add)organizationId, documentId, notificationId, actionUser, isNotificationResolverUsed, displayHeadlineMessageTemplate, displayHeadlineMessageTemplateData, displayBodyMessage, displayBodyMessageTemplate, displayBodyMessageTemplateData, notifyUsers, notificationSourceData, location, metadata, notifyAll, createDocument, createOrganization, verifyUserPermissions, context, isCrossOrganizationEnabledthe notification is the request itself — nested open-typed dicts pass through whole
UPDATE_NOTIFICATIONS_SPEC (/v2/notifications/update)organizationId, documentId, locationId, userId, verifyUserPermissions, notificationsnotifications[]: id, actionUser, displayHeadlineMessageTemplate, displayHeadlineMessageTemplateData, displayBodyMessage, displayBodyMessageTemplate, displayBodyMessageTemplateData, notifyUsers, notificationSourceData, location, metadata, context, readByUserIds, persistReadForUsers
The comment-annotation specs above reference two comment-data key sets:
  • Annotation-level commentData/comments (ANNOTATION_COMMENT_DATA_KEYS): commentText, commentHtml, commentId, from, lastUpdated, createdAt, taggedUserContacts, isCommentResolverUsed, isCommentTextAvailable, triggerNotification, triggerActivities, agent — carries the trigger flags but not context/attachments.
  • Comments-endpoint commentData/comments (COMMENT_DATA_KEYS): commentText, commentHtml, commentId, from, lastUpdated, createdAt, taggedUserContacts, isCommentResolverUsed, isCommentTextAvailable, context, attachments, agent — carries context/attachments but not the trigger flags.
UPDATE_NOTIFICATIONS_SPEC intentionally excludes isRead/isArchived — they are absent from the backend UpdateNotificationsSchemaV2 and unsupported by /v2/notifications/update, so they are dropped when filtering is on.

Organizations

Namespace: sdk.api.organizations

addOrganizations

Response

getOrganizations

Response

updateOrganizations

Response

deleteOrganizations

Response

updateOrganizationDisableState

Response

Folders

Namespace: sdk.api.folders

addFolder

Response

getFolders

Response

updateFolder

Response

deleteFolder

Response

updateFolderAccess

Response

Documents

Namespace: sdk.api.documents

addDocuments

Response

getDocuments

Response

updateDocuments

Response

deleteDocuments

Response

moveDocuments

Response

updateDocumentAccess

Response

updateDocumentDisableState

Response

migrateDocuments

Note: migrateDocuments is asynchronous and returns a migrationId. Poll completion with migrateDocumentsStatus.
Response

migrateDocumentsStatus

Response

getDocumentsCount

Response

Users

Namespace: sdk.api.users

addUsers

Response

getUsers

Response

updateUsers

Response

deleteUsers

Response

getUsersCount

Response

getDocUsers

Response

addUserInvite

Response

respondToUserInvite

Response

getUserInvites

Response

getUserInvitations

Response

getInvitedPendingUsersCount

Response

User Groups

Namespace: sdk.api.userGroups

addUserGroups

Response

addUsersToGroup

Response

deleteUsersFromGroup

Response

Notifications

Namespace: sdk.api.notifications
Filtering unknown fields: The add/update methods below accept an optional options?: FieldFilterOptions second argument. When { filterUnknownFields: true } is passed, unknown/custom keys are dropped before the request is sent, narrowing the payload to exactly the fields the Velt backend endpoint accepts. Open-typed objects (actionUser, context, metadata, user objects) pass through whole. Filtering is fail-open: if it errors, the original payload is sent, so a write is never blocked. UPDATE_NOTIFICATIONS_SPEC intentionally excludes isRead/isArchived — they are unsupported by /v2/notifications/update, so they are dropped when filtering is on. See Field Allowlist for the full per-endpoint field list.

addNotifications

  • Adds one or more notifications targeted to specific users.
  • Params: AddNotificationsRequest
  • Returns: VeltApiResponse
  • Accepts an optional options?: FieldFilterOptions second argument — pass { filterUnknownFields: true } to drop unknown fields before sending (see the note above).
Response

getNotifications

Response

updateNotifications

  • Updates existing notifications (e.g., mark as read).
  • Params: UpdateNotificationsRequest
  • Returns: VeltApiResponse
  • Accepts an optional options?: FieldFilterOptions second argument — pass { filterUnknownFields: true } to drop unknown fields before sending (see the note above).
Response

deleteNotifications

Response

getNotificationConfig

Response

setNotificationConfig

Response

Comment Annotations

Namespace: sdk.api.commentAnnotations
Filtering unknown fields: The add/update methods below accept an optional options?: FieldFilterOptions second argument. When { filterUnknownFields: true } is passed, request entity collections are narrowed to only the fields the Velt backend endpoint accepts, dropping unknown/custom keys before the request is sent. Open-typed objects (from, context, metadata, user objects) pass through whole — their nested contents are never filtered. Filtering is fail-open: if it errors, the original payload is sent, so a write is never blocked. See Field Allowlist for the full per-endpoint field list.

addCommentAnnotations

  • Creates comment annotations on a document.
  • Params: AddCommentAnnotationsRequest
  • Returns: VeltApiResponse
  • Accepts an optional options?: FieldFilterOptions second argument — pass { filterUnknownFields: true } to drop unknown fields before sending (see the note above).
Response

getCommentAnnotations

Response

getCommentAnnotationsCount

Response

updateCommentAnnotations

  • Updates fields on existing annotations (e.g., resolve them).
  • Params: UpdateCommentAnnotationsRequest
  • Returns: VeltApiResponse
  • Accepts an optional options?: FieldFilterOptions second argument — pass { filterUnknownFields: true } to drop unknown fields before sending (see the note above).
Response

deleteCommentAnnotations

Response

addComments

  • Adds comments to an existing annotation.
  • Params: AddCommentsRequest
  • Returns: VeltApiResponse
  • Accepts an optional options?: FieldFilterOptions second argument — pass { filterUnknownFields: true } to drop unknown fields before sending (see the note above).
Response

getComments

Response

updateComments

  • Updates comments within a specific annotation.
  • Params: UpdateCommentsRequest
  • Returns: VeltApiResponse
  • Accepts an optional options?: FieldFilterOptions second argument — pass { filterUnknownFields: true } to drop unknown fields before sending (see the note above).
Response

deleteComments

Response

Activities

Namespace: sdk.api.activities
Filtering unknown fields: The add/update methods below accept an optional options?: FieldFilterOptions second argument. When { filterUnknownFields: true } is passed, request entity collections are narrowed to only the fields the Velt backend endpoint accepts, dropping unknown/custom keys before the request is sent. Open-typed objects (actionUser, entityData, context, metadata) pass through whole — their nested contents are never filtered. Filtering is fail-open: if it errors, the original payload is sent, so a write is never blocked. See Field Allowlist for the full per-endpoint field list.

addActivities

  • Logs activity events.
  • Params: AddActivitiesRequest
  • Returns: VeltApiResponse
  • Accepts an optional options?: FieldFilterOptions second argument — pass { filterUnknownFields: true } to drop unknown fields before sending (see the note above).
Response

getActivities

Response

updateActivities

  • Updates existing activity events.
  • Params: UpdateActivitiesRequest
  • Returns: VeltApiResponse
  • Accepts an optional options?: FieldFilterOptions second argument — pass { filterUnknownFields: true } to drop unknown fields before sending (see the note above).
Response

deleteActivities

Response

Access Control

Namespace: sdk.api.accessControl

addPermissions

Response

getPermissions

Response

removePermissions

Response

generateSignature

Response

generateToken

Response

CRDT

Namespace: sdk.api.crdt Supports text, map, array, and xml CRDT data types.

addCrdtData

Response

getCrdtData

Response

updateCrdtData

Response

deleteCrdtData

Response

Presence

Namespace: sdk.api.presence

addPresence

Response

updatePresence

Response

deletePresence

Response

Livestate

Namespace: sdk.api.livestate

broadcastEvent

Response

Recordings

Namespace: sdk.api.recordings

getRecordings

Response

Rewriter

Namespace: sdk.api.rewriter Supports OpenAI, Anthropic, and Gemini models.

askAi

Note: askAi may take several seconds to respond. The SDK does not enforce a client-side timeout.
Response

GDPR

Namespace: sdk.api.gdpr

deleteAllUserData

Note: deleteAllUserData is asynchronous and returns a job ID. Poll completion with getDeleteUserDataStatus.
Response

getAllUserData

Response

getDeleteUserDataStatus

Response

Workspace

Namespace: sdk.api.workspace

createWorkspace

Response

getWorkspace

  • Retrieves details for the current workspace.
  • Params: empty object {}
  • Returns: GetWorkspaceResponse
Response

createApiKey

Response

updateApiKey

Response

getApiKeys

Response

getApiKeyMetadata

  • Gets metadata for the current API key.
  • Now posts to /v2/workspace/apikeyconfig/get (previously /v2/workspace/apikeymetadata/get); the method name and signature (GetApiKeyMetadataRequest, which is {}) are unchanged — no caller changes required.
  • Params: empty object {}
  • Returns: GetApiKeyMetadataResponse
Response

resetAuthToken

Response

getAuthTokens

Response

addDomains

Response

deleteDomains

Response

getDomains

Response

getEmailStatus

Response
Response

getEmailConfig

Response

updateEmailConfig

Response

getWebhookConfig

Response

updateWebhookConfig

Response

getRequestedDomains

Response

acceptRejectAdditionalUrlRequest

Response

createDomainRequest

Response

copyApiKey

Response

updateApiKeyConfig

Response

getNotificationConfig

Response

updateNotificationConfig

Response

getPermissionProviderConfig

Response

updatePermissionProviderConfig

Response

getActivityConfig

Response

updateActivityConfig

Response

ensureWorkspaceAuthToken

Response

getAdvancedWebhookConfig

Response

updateAdvancedWebhookConfig

Response

getAdvancedWebhookEndpoints

Response

createAdvancedWebhookEndpoint

Response

updateAdvancedWebhookEndpoint

Response

deleteAdvancedWebhookEndpoint

Response

getAdvancedWebhookEndpointSecret

Response

Token

Namespace: sdk.api.token

getToken

  • Generates a Velt auth token for a user via REST.
  • Params: positional — organizationId (string), userId (string), email (string, optional), isAdmin (boolean, optional)
  • Returns: VeltApiResponse
Note: getToken takes positional arguments — not a request object.
Response

Approval Workflows

Namespace: sdk.api.approval A new service for defining approval/review workflows (graphs of agent, human, and webhook nodes) and dispatching/resolving their executions and steps. 14 methods (routes live under /v2/workflow/*). Every type is Approval-prefixed. ApprovalService is also exported directly from @veltdev/node.

createDefinition

updateDefinition

deleteDefinition

getDefinition

listDefinitions

dispatchExecution

cancelExecution

getExecution

getExecutionEvents

listExecutions

cancelStep

resolveStep

recordAgentResolution

recordReviewerDecision

Node & Graph Types

These node/graph/config interfaces are referenced by the request types above. They are not standalone data-model entries.

Error Handling

The SDK exports five typed error classes:
ClassExtendsWhen thrown
VeltSDKErrorErrorBase class for all SDK errors
VeltDatabaseErrorVeltSDKErrorMongoDB connection or query failures
VeltValidationErrorVeltSDKErrorMissing or invalid request parameters
VeltTokenErrorVeltSDKErrorToken generation failures
VeltApiErrorVeltSDKErrorREST API call failures
Common self-hosting error codes returned in the response errorCode field:
  • INVALID_INPUT — Request data is malformed or missing required fields
  • INTERNAL_ERROR — Server-side error during processing
  • NOT_FOUND — Requested resource was not found

Data Models

Key interfaces and serializer helpers exported from @veltdev/node. All symbols are available at the package top level:
PartialUser and PartialAttachment referenced in the interfaces below are minimal pass-through shapes. PartialUser is { userId: string } (any additional fields the frontend sends are preserved but not strongly typed). Full user/attachment shapes are documented in the central Data Models reference.

PartialCommentAnnotation

Represents a single comment annotation thread. Used as the payload shape when reading or writing annotation data in self-hosting event handlers.
FieldTypeNotes
annotationIdstringRequired. Stable identifier for the annotation thread.
metadataBaseMetadataOptional context (document, org, API key).
commentsRecord<string, PartialComment>Keyed by commentId string.
fromPartialUserUser who created the annotation.
assignedToPartialUserUser currently assigned to the annotation.
targetTextRangePartialTargetTextRangeText selection the annotation is anchored to.
resolvedByUserIdstring | nullThree-state field — see below.
[key]unknownExtra keys pass through serialization unchanged.
Serializers:

PartialTargetTextRange

The text selection an annotation is anchored to. New interface in v1.0.2.
FieldTypeNotes
textstringRequired. The selected text content the annotation references.
Serializers:

resolvedByUserId Semantics

resolvedByUserId on PartialCommentAnnotation is a three-state field. TypeScript has no sentinel value, so the three states map to property presence and value:
StateRepresentationMeaning
AbsentProperty not set on the objectNo resolution information — do not write to the database
Explicit nullresolvedByUserId: nullAnnotation was un-resolved (cleared)
StringresolvedByUserId: "user-123"Resolved by the user with this ID
Use Object.hasOwn (or 'resolvedByUserId' in annotation) to distinguish absent from explicit null:

PartialComment

A single comment within an annotation thread. Round-trip serializers preserve unknown keys, so custom fields added by your application are not dropped.
FieldTypeNotes
commentIdstring | numberRequired. Unique within the annotation.
commentHtmlstringRaw HTML body of the comment.
commentTextstringPlain-text body, used for search and notifications.
attachmentsRecord<string, PartialAttachment>Keyed by attachment ID.
fromPartialUserAuthor of the comment.
toPartialUser[]Explicit recipients (direct-mention replies).
taggedUserContactsPartialTaggedUserContacts[]Users @-mentioned in the comment body.
[key]unknownExtra keys pass through serialization unchanged.
Serializers (new in v1.0.2):

BaseMetadata

Contextual identifiers attached to annotations and events. Provides both Velt-internal IDs and your application’s client-facing IDs for the same resources.
FieldTypeNotes
apiKeystringVelt project API key.
documentIdstringVelt-internal document identifier.
clientDocumentIdstringYour application’s document identifier.
organizationIdstringVelt-internal organization identifier.
clientOrganizationIdstringYour application’s organization identifier.
folderIdstringYour application’s folder identifier.
veltFolderIdstringVelt-internal folder identifier.
documentMetadataRecord<string, unknown>Arbitrary key-value metadata attached to the document.
sdkVersionstring | nullSDK version string. null means version is known to be absent. New in v1.0.2.
Serializers (exposed on public surface in v1.0.2):

Distribution

The package ships both CommonJS (CJS) and ES Module (ESM) bundles with rolled-up .d.ts type definitions, making it compatible with all modern Node.js project setups.