Skip to main content
  • This is currently only compatible with setDocuments method.
  • Ensure that the data providers are set prior to calling identify method.
  • The data provider methods must return the correct status code (e.g. 200 for success, 500 for errors) and success boolean in the response object. This ensures proper error handling and retries.

Overview

Velt supports self-hosting your recording annotation PII data:
  • Recorded files, recording annotation data, identity (user from field), transcription, and attachment URLs can be stored on your own infrastructure, with only necessary identifiers on Velt servers.
  • Velt Components automatically hydrate recording data in the frontend by fetching from your configured data provider.
  • This gives you full control over PII and recorded files while maintaining all Velt recorder features.

How does it work?

When recorder annotations are created, updated, or deleted:
  1. The SDK uses your configured RecorderAnnotationDataProvider to handle storage and retrieval.
  2. Your data provider implements three optional methods:
    • get: Fetches recording annotation PII from your database
    • save: Stores PII fields and returns updated transcription/attachments
    • delete: Removes PII fields from your database
The process works as follows: When a recording annotation operation occurs:
  1. The SDK first attempts the operation on your storage infrastructure
  2. If successful:
    • The SDK updates Velt’s servers with minimal identifiers
    • The RecorderAnnotation object is updated with isRecorderResolverUsed: true while PII is being fetched
    • Once PII is available, the annotation is hydrated with identity, transcription, and attachment data
  3. If the operation fails, no changes are made to Velt’s servers and the operation is retried if you have configured retries.

Implementation Approaches

You can implement recorder self-hosting using either of these approaches:
  1. Endpoint based: Provide endpoint URLs and let the SDK handle HTTP requests
  2. Function based: Implement get, save, and delete methods yourself
Both approaches are fully backward compatible and can be used together.

Endpoint based DataProvider

Instead of implementing custom methods, you can configure endpoints directly and let the SDK handle HTTP requests.

getConfig

Config-based endpoint for fetching recording annotation PII. The SDK automatically makes HTTP POST requests with the request body.

saveConfig

Config-based endpoint for saving recording annotation PII. The SDK automatically makes HTTP POST requests with the request body.

deleteConfig

Config-based endpoint for deleting recording annotation PII. The SDK automatically makes HTTP POST requests with the request body.

Endpoint based Complete Example

Function based DataProvider

Implement custom methods to handle data operations yourself.

get

Fetch recording annotation PII data from your database. Called when annotations need to be hydrated in the frontend.

save

Store recording annotation PII fields. Called when a recorder annotation is created or updated.

delete

Remove recording annotation PII from your database. Called when a recorder annotation is deleted.

config

Configuration for the recorder data provider.
  • Type: ResolverConfig. Relevant properties:
    • resolveTimeout: Timeout duration (in milliseconds) for resolver operations
    • getRetryConfig: RetryConfig. Configure retry behavior for get operations.
    • saveRetryConfig: RetryConfig. Configure retry behavior for save operations.
    • deleteRetryConfig: RetryConfig. Configure retry behavior for delete operations.
    • additionalFields: string[]. Specify additional fields from the RecorderAnnotation object to include in the resolver request payloads sent to your backend. By default, only core PII fields (identity, transcription, attachment URLs) are sent. Use this to request extra fields you need (e.g., recordedTime, pageInfo).

uploadChunks

Controls whether recording media is uploaded as individual chunks during recording, or as a single full recording after the annotationId is assigned.
  • Type: boolean
  • Default: false (upload full recording)
Set to true to upload individual chunks as they are recorded, which can be useful for long recordings or unreliable network conditions.

storage

A scoped AttachmentDataProvider for recorder media files. Use this to route recording file uploads to a separate storage backend from your default attachment provider.

Function based Complete Example

Sample Data

The recorded media file (audio/video) can be stored at any file storage provider of your choice (e.g., AWS S3, Google Cloud Storage, Azure Blob Storage, or your own servers). The url field in the attachment object points to wherever you host the file.
The recording annotation on your database stores the actual media file URL, MIME type, file name, size, and the user identity (from). The url field points to wherever you host the recorded file — any file storage provider works.

Loading and Upload State Fields

Two fields on RecorderAnnotation indicate recorder resolver status:

Debugging

You can subscribe to dataProvider events to monitor and debug recorder resolver operations. Filter for the RecorderResolverModuleName.GET_RECORDER_ANNOTATIONS module name to isolate recorder-specific events. You can also use the Velt Chrome DevTools extension to inspect and debug your Velt implementation. RecorderResolverModuleName — Enum of module names for recorder resolver events.