Dev mode and capture

Turning it on

Set authoring.enabled on init. A record button appears for the user. The key you initialise with has to carry the authoring capability, which you grant in the admin console or with the grant-authoring-capability script. A plain publishable key cannot publish flows.

NudgeSDK.init({
  apiKey: "pk_…",          // must have the authoring capability
  apiBase: "https://your-backend.com/api",
  authoring: { enabled: true, aiAssist: true },
});

Recording a walkthrough

1. Click the record button. The recorder starts watching your clicks.
2. Do the task exactly as a user would: click the buttons, fill the fields, in order.
3. Stop. The captured clicks become an ordered list of steps.
4. With aiAssist: true (the default) the backend writes the instruction text and a flow title from what you captured. With it off, you keep the raw captured labels.

What never gets recorded

The recorder is conservative by default. It never captures password or credit-card inputs, and it skips anything marked data-nudge-skip. Add more selectors to redact through the privacy option:

privacy: {
  redactSelectors: [".ssn", "[name='dob']"],
  replaceDefaults: false,   // keep the built-in password protection
}

It records the element identifier and the action, not the values a user typed. Input steps are marked as redacted so the admin console shows "(redacted)" rather than the content.

Local-first capture during development

There is a separate path meant for the inner dev loop. While you run your app locally, click capture can write to a local .nudge/cache/ directory instead of the network, then upload in a batch. Two commands drive it:

npx nudge bootstrap   # create .nudge/cache and gitignore it
npx nudge sync        # upload the cached batches to your backend

• bootstrap is idempotent and adds .nudge/ to your .gitignore so captures never get committed.
• sync reads NUDGE_API_KEY from the environment and uploads. A failed batch stays queued and retries on the next run.