JavaScript API

Once the script loads, the widget exposes one global function:

window.produck(command, ...args)

Everything here is optional — the widget works fully with just the script tag.

Command	Arguments	What it does
`identify`	`{ userId?, email?, name? }` · `{ jwt }` · `null`	Attach the current user’s identity to their feedback (or `null` to clear on logout).
`trigger`	—	Open the widget from your own UI.
`fire`	`triggerId`	Offer the campaign interview for one of your campaign’s triggers.
`config`	`{ launcher?, confirmation? }`	Choose who owns the injected launcher and confirmation UI.
`on`	`eventName, callback`	Listen for `submit`, `submit_error`, `close`, or `survey_complete`.
`destroy`	—	Remove the widget and its listeners from the page.

Identify your users

Tell Produck who’s giving feedback so each submission ties back to a real user instead of being anonymous. Call identify once you know who they are — typically right after login.

window.produck("identify", {
  userId: "user_123",
  email: "ada@example.com",
  name: "Ada Lovelace",
});

All three fields are optional — send whatever you have. Already holding the user’s session token? Hand it over and we read the standard sub / email / name claims for you — one line for Supabase, Auth0, Clerk, Firebase, or Cognito:

window.produck("identify", { jwt: session.access_token });

We only read the claims (the signature is not verified), so this labels feedback inside your own project — it is not an authentication check.

Server-rendered pages (no JavaScript)

If your backend already knows the user at render time, set data-user-* on the script tag and skip identify entirely. data-user-jwt works the same way if you’d rather pass a token:

<script src="https://tryproduck.com/sdk/v1.js" data-project="pk_live_YOUR_KEY"
        data-user-id="user_123" data-user-email="ada@example.com" data-user-name="Ada Lovelace" defer></script>

Clear identity on logout

window.produck("identify", null);

If you need to identify a user before the script finishes loading, queue the call first. The widget replays anything queued the moment it boots, so nothing is lost:

<script>
  window.produck = window.produck || function () {
    (window.produck.q = window.produck.q || []).push(arguments);
  };
  window.produck("identify", { userId: "user_123" });
</script>

<script src="https://tryproduck.com/sdk/v1.js" data-project="pk_live_YOUR_KEY" defer></script>

Wire up your own “Give feedback” button with trigger:

document.querySelector("#feedback-button").addEventListener("click", () => {
  window.produck("trigger");
});

Fire a campaign trigger

Each trigger on a campaign’s Triggers tab has an id. When the moment it describes happens on your page, fire it, and the widget offers the visitor that campaign’s interview:

window.produck("fire", "TRIGGER_ID");

A server-rendered page can fire one with no script at all. Render a hidden element carrying the trigger id, and the widget fires it once it boots, or as soon as the element is added to the page later, so fragments swapped in by HTMX or Turbo fire too:

<span data-produck-fire="TRIGGER_ID" hidden></span>

The offer says the trigger’s What should the trigger say to the end user? text, or “Got a minute to tell us how that went?” when it has none. A trigger fires at most once per browser tab session, so repeated calls, re-renders and later page loads in the same tab show no second offer. A fire shows nothing, and says why on the console, when the trigger is paused or its campaign isn’t live, a recording is already in progress, or the browser cannot record the screen. Accepting the offer starts the recording, and the interview is attributed to the trigger. Only the recording that accepted offer starts is attributed: a recording opened later from the Produck button, trigger or the shortcut carries no trigger, even after a declined offer. The offer shows even when the page hides the Produck button with data-launcher="none". It then sits on its own in the bottom-right corner, and once it’s declined or the recording is done the page shows nothing again.

Listen for events

React when a user submits or dismisses the widget — for example, to show a thank-you toast.

window.produck("on", "submit", () => {
  showToast("Thanks for the feedback!");
});

window.produck("on", "close", () => {
  // the widget surface closed
});

Event	Fires when
`submit`	Feedback is successfully submitted. May fire after `close` when a failed submission is retried. Payload: `{ feedback_id, share_url }` — `share_url` is the ticket’s public link (its share page on the dashboard), present only when the ticket was created link-viewable; a ticket created private carries `feedback_id` alone.
`submit_error`	A submission fails. Payload: `{ error, retry }` — call `retry()` to resubmit the same feedback (re-fires `submit` on success).
`close`	The widget surface closes — after a submit, a cancel, or a failed submit. A ticket filed without review (the workspace’s preview is off and the recording is narrated) opens no surface and fires no `close`.
`survey_complete`	The reporter stops a scripted run’s recording from the record bar, before the ticket composer opens over the recording, or before the ticket is filed without review when the workspace’s preview is off. Payload: `{ outcome, answered, answers }` — `outcome` is `completed` (the closing line had been spoken when they stopped) or `reporter_stopped` (stopped earlier, after at least one answer), `answered` the number of questions answered. `answers` lists the asked lines and the reporter’s answers in script order, each as `{ node, question, answer }` where `node` is the id of the script line answered; an answer to a line that asked the visitor to show something on the page also carries `marked`, the names of the page elements they marked while the line awaited its answer, in mark order, absent when none. `submit` follows with the ticket id once the reporter creates the ticket from the composer or the filing lands, or `submit_error` if the save fails; a discarded composer files nothing. A run stopped before any answer opens the composer but does not fire this.

Scripted acts

A scripted flow can type into, select and click elements on your page as the visitor answers. Mark each element the script names with data-produck-target="<name>" — a text field receives, when the visitor’s answer commits, the value the script judged from their words — never the raw transcription — typed through its own value setter followed by a bubbling input event, so a React- or Vue-controlled input sees the change; anything else is clicked. A script can also signal a marked element instead of clicking it: the widget dispatches a bubbling produck:signal event on the element with the signal’s name in detail.name, draws the done ring, and leaves what the signal does to your page. The widget reads the marked targets at every answer and names what it read in its next acknowledgement. The widget draws a focus ring on a target a line asks the visitor to use themselves, and a done ring on every target it fills or clicks. A target missing from the page is reported on the console and the script carries on.

Bring your own UI

The widget injects two surfaces you can take over. Each is an ownership setting, not a boolean, so it stays meaningful as more options arrive:

Surface	Values	Default
`launcher`	`droplet` · `none`	`droplet` (the floating duck button)
`confirmation`	`toast` · `none`	`toast` (the post-submit success/error toast)

Set none on a surface to suppress the built-in version and render your own. Turning a surface off never removes capability — trigger, fire, submit, and submit_error keep working. The droplet is additionally suppressed where the browser cannot record a tab (no display capture, as on mobile browsers); trigger deliberately still works there, so a custom launcher keeps its contract.

produck("config", { launcher: "none", confirmation: "none" });

// your launcher
document.querySelector("#feedback-button").addEventListener("click", () => produck("trigger"));

// your confirmation
produck("on", "submit", () => myToast.success("Thanks!"));
produck("on", "submit_error", ({ error, retry }) => {
  myToast.error("Couldn't send — retry?", () => retry());
});

Set the same thing with no JavaScript using data-* attributes on the script tag:

<script src="https://tryproduck.com/sdk/v1.js" data-project="pk_live_YOUR_KEY"
  data-launcher="none" data-confirmation="none" defer></script>

To call config before the script finishes loading, queue it with the same stub shown above for identify — the widget replays it on boot.

Keep your own Capture Handle

Before a tab recording the SDK tags the page with its own Capture Handle, so it can tell a capture of this very page from a capture of another tab. A page that already sets a handle for a companion capturer — a conferencing app, say — keeps it by declaring it with data-capture-handle. The SDK then reads that handle and leaves the page’s Capture Handle configuration alone. List your own origin in the handle’s permittedOrigins, because the SDK opens its capture from your page.

<script src="https://tryproduck.com/sdk/v1.js" data-project="pk_live_YOUR_KEY"
  data-capture-handle="my-conferencing-handle" defer></script>

The keyboard shortcut (⌘/Ctrl + Shift + ?) still opens the widget when launcher is none — it’s an invisible trigger, not a visible surface. Rebind it with data-shortcut, or unbind it with data-shortcut="off", so your launcher is genuinely the only way in — see Keyboard shortcut.

Clean up on logout

Call destroy to remove the widget when a user’s session ends. On shared devices, this keeps the next user from seeing the previous one’s identity.

window.produck("destroy");

Get started

Widget

Identify your users

Server-rendered pages (no JavaScript)

Clear identity on logout

Open the widget from your own UI

Fire a campaign trigger

Listen for events

Scripted acts

Bring your own UI

Keep your own Capture Handle

Clean up on logout

​Identify your users

​Pass a login token (JWT)

​Server-rendered pages (no JavaScript)

​Clear identity on logout

​Open the widget from your own UI

​Fire a campaign trigger

​Listen for events

​Scripted acts

​Bring your own UI

​Keep your own Capture Handle

​Clean up on logout

Identify your users

Pass a login token (JWT)

Server-rendered pages (no JavaScript)

Clear identity on logout

Open the widget from your own UI

Fire a campaign trigger

Listen for events

Scripted acts

Bring your own UI

Keep your own Capture Handle

Clean up on logout