Software Demand Signals — June 24, 2026

Proactive, expiry-based OAuth2 token refresh for automation tools (handle APIs that return HTTP 200 with an error body)

dev tool weekend hack •• multiple requests

n8n's generic OAuth2 only refreshes a token reactively when an API returns HTTP 401, but services like Adobe Marketo return HTTP 200 with the error inside the response body, so the token silently goes stale and the integration breaks. Multiple builders independently want refresh driven by the token's own expires_in value inside the credential boundary, rather than trusting status codes.

builder note

The non-obvious bug is that 'token expired' is not the same as 'HTTP 401' for a meaningful set of enterprise APIs; refresh proactively off the token's expires_in (with a safety margin) instead of trusting the status code, and you fix a whole class of silent integration failures that status-code-based refresh can never catch.

landscape (2 existing solutions)

Automation tools assume an expired token surfaces as HTTP 401, but real-world APIs (Marketo and friends) return 200 with an error in the body, so refresh-on-401 fails silently. The unmet need is proactive refresh based on expires_in inside the credential, and n8n's maintainers closed the escalation as working-as-expected, leaving the demand open.

n8n generic OAuth2 credential Refreshes tokens only reactively on an HTTP 401, so any API that signals expiry via a 200-with-error-body silently keeps using a dead token until the workflow fails.

Hand-rolled HTTP Request node workaround Forces builders to re-implement OAuth2 refresh logic in plain HTTP nodes per integration, losing the convenience and security of the managed credential.

sources (1)

other https://community.n8n.io/t/generic-oauth2-authentication-enf... "Some APIs return HTTP 200 with error messages in the response body instead of standard error codes" 2026-06-11

workflow-automationoauth2n8napi-integrationtokens

Merge or link related conversations in open-source helpdesks without losing context

saas real project •• multiple requests

Self-hosted helpdesks like Chatwoot have no first-class way to merge, link, or group conversations that belong to the same customer issue, so a customer emailing from two addresses, a reply that spawns a new thread, or an issue spanning mailboxes each becomes an isolated conversation that breaks context, SLA tracking, and reporting. Users broadly ask for conversation merge; one later proposal argues a non-destructive parent Case container may preserve history better. Maintainers concede interest but have no agreed data model.

builder note

The evidence supports a context-continuity problem first, not a settled Case-first spec. Start by preserving every original conversation and making related threads visible together; then test whether users prefer direct merge, linked siblings, or a parent Case object for reporting and workflow.

landscape (3 existing solutions)

Closed helpdesk SaaS has merge and linking; open-source helpdesks don't, so cross-address and cross-mailbox conversations break context, SLA, and reporting. The unresolved product question is whether to ship direct merge, linked conversations, or a parent Case model without corrupting history and reporting.

Chatwoot Has neither conversation merge nor case grouping, so related conversations stay isolated; the open issues confirm there is no agreed data model yet.

Freescout Multi-mailbox replies can fragment a single customer conversation into several separate threads, the same context-loss problem from a different angle.

Zendesk / Freshdesk / Front Closed SaaS incumbents that DO offer ticket merge and linked/sibling tickets, the exact capability the open-source tools lack, but at SaaS pricing and without self-hosting.

sources (2)

other https://github.com/chatwoot/chatwoot/issues/9264 "It would be nice to merge that conversation with the previous conversation" 2024-04-19

other https://github.com/chatwoot/chatwoot/issues/9264#issuecommen... "Chatwoot could introduce a new Case entity" 2026-04-09

helpdeskcustomer-supportopen-sourceself-hostedcrm

Per-execution dynamic credential selection for multi-tenant workflow automation (pick the tenant's credential at runtime)

saas real project ••• trending

Agencies and SaaS teams using n8n as their automation backend cannot choose which saved credential a node uses via an expression at runtime, so one logical workflow becomes 100+ duplicated nodes (one per client) or a fragile community-node hack. They want a single workflow that resolves the right per-tenant credential from the execution data. The canonical request thread is five years old and still drawing replies this week.

builder note

Don't build another Zapier; the wedge is multi-tenant. Agencies and SaaS embedding automation need one workflow that resolves a tenant's credential at execution time. The security-review burden of injecting arbitrary credential IDs is both the reason incumbents leave it static and the moat if you solve it safely (scoped, permissioned references rather than raw IDs).

landscape (3 existing solutions)

Every mainstream automation engine binds credentials statically, so multi-tenant builders duplicate nodes per client or hack around it. Declarative, secure runtime credential resolution is the unmet need; the security-sensitivity of injecting arbitrary credential references is exactly why engines keep it static.

n8n Credentials are bound to a static dropdown per node at design time; there is no supported expression-based selection, forcing node duplication for multi-tenant fan-out.

n8n-nodes-run-node-with-credentials-x (community node) A community workaround that wraps a node to inject a chosen credential, but it is unofficial, fragile, and not maintained as a first-class capability.

Make / Zapier Connections are also bound per-step at design time, with no per-execution credential resolution keyed off workflow data.

sources (2)

other https://community.n8n.io/t/dynamic-credential-selection-via-... "Credentials in n8n nodes must be selected statically at design time" 2025-12-15

other https://community.n8n.io/t/select-credentials-via-expression... "I actually was able to use this approach with a multi-tenancy database structure to dynamically select the database" 2026-06-22

workflow-automationmulti-tenantn8ncredentialsagency

First-class event retention (TTL) and arbitrary event deletion for self-hosted product analytics

saas real project ••• trending

Operators of self-hosted PostHog can delete a known person and their associated events, but they still lack first-class event retention windows and arbitrary event/event-name deletion for cleanup, retention-policy enforcement, and compliance edge cases. Demand is hot and current: two long-running open issues are collecting fresh +1s from users and customer-facing support threads.

builder note

It reads like a feature request but it's really an operations/compliance product: the +1s cite retention policies, privacy requirements, bad event cleanup, and ballooning ClickHouse storage. The hard part isn't a delete button, it's propagating TTL and targeted deletion across partitions and materialized views, which is precisely why a retention/cleanup layer for self-hosted event stores has room to exist.

landscape (3 existing solutions)

Self-hosted product-analytics stores let you ingest unlimited events but still give operators no first-class way to expire old events or delete arbitrary bad/sensitive event sets. Deletion across a columnar event store with materialized views is genuinely hard, which is why TTL and targeted cleanup stay underbuilt.

PostHog (self-hosted) Supports deleting known persons and their associated events, but not per-project event TTL/auto-expiry or arbitrary event/event-name deletion; teams still hit storage growth, retention-policy, and cleanup/compliance gaps.

Plausible / Matomo Lighter, privacy-friendly analytics with retention controls, but not full product analytics (funnels, cohorts, session replay, event pipelines) that PostHog users need.

Mixpanel / Amplitude Offer data-deletion and retention controls, but are cloud SaaS, which defeats the reason these teams self-host in the first place.

sources (2)

other https://github.com/PostHog/posthog/issues/17031#issuecomment... "+1 please implement this. For GDPR reasons this is **very** important" 2026-06-23

other https://github.com/PostHog/posthog/issues/19468 "Posthog currently doesn't allow for the deletion of events" 2023-12-21

analyticsgdprdata-retentionself-hostedcompliance

A modern, local-first GUI for real small-business double-entry bookkeeping (the gap between QuickBooks and GnuCash)

desktop app real project •• multiple requests

Sole proprietors and small-business owners want to own their financial data on their own machine but find GnuCash dated and hard to set up while QuickBooks is cloud-pushed, pricey, and built for businesses that already have a bookkeeper. The repeated ask is a GUI-first double-entry app that sits in the middle; one current commenter explicitly makes open source a hard requirement, while another frames the same gap around data ownership and local control.

builder note

Do not lead with another cloud ledger. The shared demand is local control, data ownership, and lower setup friction than GnuCash; open source strengthens trust for at least part of the audience, but the wedge is GnuCash's double-entry correctness wrapped in modern onboarding.

landscape (4 existing solutions)

GnuCash owns correctness but not UX; the cloud incumbents own UX but not data ownership; and the emerging local/open-source GUIs are still early. A polished, approachable, local-first double-entry app for small businesses is the specific unmet middle.

GnuCash Correct double-entry accounting but a dated UI and high setup friction; the users themselves call it 'too hard to set up' and tiring to maintain for daily entry.

QuickBooks Dominant but increasingly cloud-pushed with climbing subscription pricing, and assumes a business already has a bookkeeper; the opposite of the data-ownership, low-friction ask.

Firefly III Self-hosted and data-owned, but oriented to personal budgeting rather than business double-entry books.

Frappe Books / Bigcapital Newer open-source GUI desktop/self-host options moving into exactly this gap, but still maturing and far less known than GnuCash, so users keep defaulting to and complaining about GnuCash.

sources (2)

hn https://news.ycombinator.com/item?id=48476947 "There's space for a more GUI-focused option that isn't Quickbooks or Gnucash" 2026-06-10

hn https://news.ycombinator.com/item?id=48548705 "GNUcash is too hard to set up" 2026-06-15

bookkeepingaccountinglocal-firstdata-ownershipsmall-business