Skip to main content

JavaScript Examples

All examples use the native fetch API and work in browsers and Node.js 18+.
For other languages (Python, Go, Ruby, .NET) used in server-side / batch / queue-worker integrations, see Server Integration. For AI agent tool registration patterns (OpenAI, Anthropic, LangChain, LlamaIndex), see Agent Tool Integration.

Basic chat with document

EventSource streaming

Upload document and export

See Exporting documents for the full options reference and the upload-then-export pattern for documents over 20 MB.

File upload

Job polling

HITL approval

HITL approval with SSE streaming (real-time progress)

The polling pattern above is fine for server-to-server flows where no human is watching. For interactive editor integrations — where a user is staring at the chat panel waiting for their edit — open the SSE stream alongside the async job so progress events arrive in real time and the UI never goes silent for more than a few seconds.
When to use streaming vs polling.
  • Streaming — interactive editor UIs, any flow where a user is watching. Users see progress text within 1–5 seconds, and the turn’s proposed changes arrive together in one proposed_change_batch event ready to render as a review list.
  • Polling — background batch processing, server-to-server flows, queues where the user isn’t waiting. Simpler to implement; perfectly fine when latency feedback isn’t a UX requirement.
See Streaming → Rendering intermediate events for the in-flight bubble pattern, and Async jobs → Latency expectations for typical operation durations.

Frontend layout

Most products that integrate SuperDocs converge on a two-pane layout: the document editor on the left (primary area) and a chat panel on the right (fixed width, 380–440 px). The skeleton below is framework-agnostic — the same shape works in React, Vue, Svelte, or plain HTML.
Notes on the pattern:
  • Inline diff overlays render inside the editor pane (see Rendering diffs inline in your editor). The chat pane only holds the message log and the batch-approve bar.
  • The chat panel reads editor HTML before every send and writes it back on every final event. Expose this through a ref / store so the chat doesn’t have to know about your editor’s internals.
  • One session per tab. Generate a random session_id on page load and reuse it for every request in that tab. SuperDocs persists conversations across server restarts.
  • API key stays server-side. If you’re building a browser app, proxy SuperDocs calls through your own backend so sk_... never reaches the browser. See the streaming guide for the api_key query-parameter workaround for EventSource, which cannot set custom headers.