Skip to main content
Send your agent’s conversations to BuildBetter to find user friction, misunderstood requests, and opportunities to improve responses. Send message feedback separately to distinguish explicit ratings from findings extracted through qualitative analysis.
The Node SDK, @buildbetter/ai, is a preview and is not published to npm. The SDK examples below describe the preview interface, not an installable release. Use the Agent Chats HTTP API for an integration today.

Set up your destination

  1. Open Library → Agent Chats → Set up Agent Chats in the destination workspace. Ask an administrator if Agent Chats is unavailable.
  2. Create an application, such as Support assistant, with a stable key, such as support-agent.
  3. Set its access policy, content capture, redaction, retention, and allowed environments before sending customer data.
  4. Create an ingest credential. Save the secret when it appears. BuildBetter shows it once.
An application represents the agent or product that sends conversations. It groups those conversations and sets their ingestion and access rules. Keep the credential in your server’s secret manager. It is an ingestion-only secret, not your organization API key. Never send it to a browser. Use an application key and credential created in the destination environment. The credential selects the workspace. context.environment describes your source environment and does not select the destination. Enabling Agent Chats does not connect any agent automatically. Customers connect their own agents to their own workspaces. It does not grant access to another workspace’s chats.

Start with HTTP

The HTTP API works from any language. Send a server-side POST to /v3/rest/agent-conversations/ingest with:
  • Header X-BuildBetter-Agent-Key: your ingest secret.
  • Header Content-Type: application/json.
  • Body agentKey: your application’s stable key.
  • Body externalSessionId: your conversation ID.
  • Body events: messages or feedback with stable event IDs, sequences, and timestamps.
Follow the complete conversation example, then send the feedback example. Both use the same session. No SDK package is required.

Node SDK preview

The preview requires Node.js 20 or later. The root package supports ESM and CommonJS. This example uses ESM. The variables below represent server configuration. Set the secret outside your source code.
Use your persisted IDs and timestamps in place of these sample values. Include the source environment and account in IDs when multiple accounts share one destination application. The SDK uses positive odd message sequences and reserves the next even sequence for feedback. This example uses explicit sequences so later batches keep their positions. Without explicit sequences, send the complete visible history in its original order. Names, usernames, and emails support participant identification. user.id maps to the HTTP field externalId, and user.name maps to displayName. External identities do not create BuildBetter users or Persons.

Add thumbs-up, thumbs-down, or written feedback

Send feedback from your authenticated server after it verifies that the user can access the target message. For the assistant response above:
Use positive for a good response and negative for a bad response. Supply at least one rating, label, or comment. messageSequence is the target assistant’s sequence, not the feedback sequence. The preview SDK keeps one feedback event per target message. Increase revision when that feedback changes. Independent votes from multiple people require distinct feedback events through the HTTP API. Explicit feedback creates a Signal without model credits. Qualitative analysis of finalized assistant responses uses response credits. Use the Agent Chat source filters in Signals to separate explicit feedback from inferred findings.

Vercel AI SDK preview

The optional wrapper supports Vercel AI SDK 7 (ai@^7.0.0) and uses the ESM subpath @buildbetter/ai/vercel. Your provider package must support that AI SDK version.
The wrapper captures visible user and assistant text. It excludes system prompts, reasoning, files, and tool inputs and outputs. Capture errors do not fail the model request. For persisted message IDs, edited responses, or message feedback, use capture() after saving finalized messages. The preview wrapper derives its own IDs and does not return a mapping to your UI message IDs. Do not combine wrapper capture and direct capture for the same session.

Delivery and retries

  • Persist message IDs, sequences, revisions, and timestamps before sending. Reuse them for retries.
  • Increase revision when an existing event changes. Keep its sequence and type unchanged.
  • With the SDK, send new messages with explicit odd sequences. Do not mix raw HTTP event numbering with SDK numbering in one session.
  • Send status: "ended" or "abandoned" when the conversation ends. Include at least one event, such as a replay of the final message.
  • Await delivery before the process exits. Use a durable server queue when delivery must survive request or process failures.
  • Direct SDK methods throw on failure. They do not provide a durable queue or automatic retries. Retry transient failures with bounded backoff and stable event data.
  • The SDK batches requests and truncates oversized visible text. The HTTP limits are 500 events, 2 MiB per request, and 256 KiB per event.
Fix authentication and payload errors before retrying. See the response codes.

Confirm the integration

  1. Send a synthetic conversation with a unique session ID and a known surface.
  2. Confirm the session appears in Library → Agent Chats in the intended workspace.
  3. Send negative feedback on its assistant response. Confirm the rating and message link.
  4. Retry the unchanged payload. Confirm the API reports deduplicated events instead of a second conversation.
  5. Check access with an account outside the application’s allowed users.
An accepted response with processingStatus: "pending" confirms ingestion, not completed signal extraction. Check the conversation after processing finishes. Before sending real data, review the privacy settings. When ownerUserId is omitted, the application’s access policy controls visibility, with workspace access as the default. For owner-only chats, use an active BuildBetter user UUID from the destination workspace, not an external participant ID.