Skip to content

Zapier integration: a "note ready" trigger surface (webhook-first) #414

Description

@Optic00

Second half of ruzin's integrations push (Obsidian tracked separately). Zapier is the bigger lift because Steno currently has no event surface an external automation can subscribe to.

Proposed staging

Stage 1 - outgoing webhook (no Zapier account needed, generic): a setting (off by default) to POST a JSON payload to a user-configured URL when a note finishes processing ("note ready"): title, date, folder, summary markdown, optionally the transcript (separate toggle - privacy). With Zapier's "Webhooks by Zapier" trigger this already enables Slack/Notion/CRM/etc. flows without us building anything Zapier-specific. Also works with n8n/Make/self-hosted automation - fits the privacy-conscious user base better than a hosted-only path.

  • Privacy defaults: off by default, explicit opt-in, clear disclosure that the payload leaves the machine, transcript excluded unless separately enabled.
  • Delivery: fire-and-forget with one retry; failures logged, never blocking the pipeline.

Stage 2 (optional, later) - a listed Zapier app: requires a hosted trigger API + auth story, i.e. real server-side infrastructure Steno deliberately doesn't have today. Only worth evaluating if Stage 1 sees real usage. Possibly ties into the org adapter rather than the desktop app.

Open questions

  • Payload schema: worth versioning from day one (schema_version) so integrations don't break.
  • Should "recording started/stopped" events be included, or notes only? (Notes-only keeps the privacy story simplest.)
  • HMAC signature header for receivers that want authenticity?

Non-goals (this issue)

A hosted Zapier app, incoming webhooks/remote control, per-event filtering UI.

Activity

  1. Optic00 commented on Sep 8, 2026

    @Optic00
    CollaboratorAuthor

    #542 proposes optional validated fields in report templates; #543 covers their Obsidian export. The same data could be an optional part of this webhook payload, using the report's schema identity and revision rather than defining a second extraction format.

    For delivery, keep an event ID stable across retries so receivers can deduplicate. A newly generated report revision should be distinguishable from a retry. Version the event envelope separately from the user-defined field schema, and do not send invalid or stale fields as current results.

    For example, n8n could turn reviewed action items into Jira tickets, with project mapping and ticket creation handled by the workflow. That keeps Jira out of Steno's integration scope and preserves the existing opt-in and transcript defaults.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions