Paperclip merges Fireflies meeting access, with live webhook proof still pending

Paperclip merged Fireflies support on September 23, connecting meeting material to its existing Apps and Routines surfaces rather than creating a separate automation system. The feature combines authorized MCP access to transcripts and summaries with a signed incoming-event path. Its documentation is unusually useful about where those two capabilities meet—and where they do not.

The implementation report describes a real OAuth connection, discovery of 20 actions, and successful meeting-list, transcript and summary retrieval. It also reports that turning a read action off blocked its test and that refreshing the catalog preserved that restriction. The missing piece is equally explicit: a real Fireflies webhook from a newly completed meeting has not been verified.

The facts

- PR 13890 merged on September 23; this is merged-source evidence, not proof that every deployed Paperclip installation includes it. - The connector uses the ordinary vault, connection grants, permissions and audit path, with OAuth or an API-key option. - The authors report 20 discovered live actions and successful transcript and summary reads under the selected agent. - The shared app webhook flow authenticates exact request bytes and treats payload content as external data. - New generic triggers depend on choosing Meeting Summarized at the sender; they do not infer a Fireflies-only event filter. - Identical signed bodies are deduplicated, but changed bytes can count as a new event without a sender-supplied idempotency key.

Why it matters

Meeting automation has two independent failure modes: an agent can receive an event without permission to retrieve the meeting, or it can have access without receiving the event that should start the work. Paperclip's design keeps those questions separate. That makes it possible to audit a missed follow-up without treating a successful OAuth screen as proof that the whole workflow works. It also keeps incoming JSON from silently acquiring the authority of the operator's instructions.

Current

Checked September 24, 2026. The inspected release baseline is v2026.916.1. The primary source is merged 2026-09-23T22:11:17Z. Package availability and development-source state are separate: a tag does not establish that an open proposal is usable, and a merge does not establish that every installation has received it.

Evidence

Primary: paperclipai/paperclip PR #13890 (https://github.com/paperclipai/paperclip/pull/13890). Supporting context: paperclipai/paperclip — FIREFLIES.md at c54174fa (https://github.com/paperclipai/paperclip/blob/c54174faa13ed82c5239ce03a0f8ce4acb4dfcd4/doc%2Fconnections%2FFIREFLIES.md); paperclipai/paperclip PR #13890 — implementation diff (https://github.com/paperclipai/paperclip/pull/13890/files). Source pages and available diffs were inspected; test and live-account results remain attributed to their authors, not independently repeated measurements.

Operator take

Evaluate the connection and trigger as separate acceptance tests. Confirm the intended agent can read the intended meeting, that denied actions remain denied after reconnection, and that a real summary-ready event produces one appropriate task. Use the provider's summary event subscription rather than assuming the generic receiver filters every event. The linked connection document supplies the operational boundaries; none of its live-account claims were independently repeated for this story.

Caveat

The live account reads are author-reported. Real provider webhook delivery, live API-key authorization and credential-expiry behavior remain unverified in the stated acceptance record. Some older validation prose describes summary-specific filtering; the final new generic flow instead leaves event selection to the sender. A webhook receipt alone conveys no Fireflies tool permission.