velt-self-hosting-data-best-practices

Configure a comment data provider on VeltProvider using either endpoint-based config (URLs the SDK calls automatically) or function-based resolvers (get, save, delete callbacks). Your backend must return the standard { data, success, statusCode } response format for every operation.

Use endpoint-based config when you have standard REST endpoints and want the SDK to handle HTTP requests and retries. Use function-based resolvers when you need custom transformations, multi-system writes, conditional routing, or non-REST backends.

Attachment saves use multipart/form-data encoding, not JSON like other providers, so a backend expecting JSON receives an undefined file. Do not set the Content-Type header manually, and ensure the save response includes { data: { url } } pointing to the stored file.

Yes. Initialize VeltSDK with only apiKey and authToken to use sdk.api.* services, which call Velt REST APIs directly with no MongoDB required. The database config is only needed for sdk.selfHosting.* operations.

Self-hosting only works with setDocuments (plural), not setDocument (singular). Data providers must also be registered on VeltProvider via the dataProviders prop before authentication, otherwise data flows to Velt servers instead of your infrastructure.

Every handler must return { data, success, statusCode }. Missing fields or wrong names like 'status' instead of 'statusCode' cause the SDK to treat the response as a failure and trigger retries.