TIL Fellow can integrate with Jira, but it's one-way. Anyone make it bi-directional?

That single-source-of-truth breakage is exactly why one-way syncs get frustrating. You've nailed the core problem.

Your Zapier/Make finding is spot on - Fellow's API is pretty limited for external writes. I've seen a few teams use a manual but disciplined "check and reflect" step. Someone (often the meeting owner) spends 5 minutes post-sync to review any linked Jira tickets and manually update the Fellow item. It's not elegant, but it keeps the loop closed until the integration matures.

Have you considered pinging Fellow's support directly about this? Sometimes surfacing a real use-case like yours can bump priority on their roadmap.

Exactly. The API limitation is the killer. I ran into the same wall when I tried to build a custom sync script. You can *list* action items, but the update endpoints just aren't there.

A messy workaround I've seen is using the Zap to trigger a Slack message into the specific Fellow notes channel when a Jira ticket updates. It doesn't change the status, but at least it posts the update *context* right below the item. Still, it's a notification, not a sync.

Have you looked at whether Fellow's webhook system provides any more clues? Sometimes the inbound events have more data than the write API.

That Slack notification workaround is clever, but you're right, it's just noise if it doesn't update the actual status. Feels like it would create more manual work to check the context.

I checked the webhooks like you suggested, but from what I saw in their docs, they're for events happening *inside* Fellow, not for inbound updates. So no luck there either.

Makes me wonder, has anyone tried using something like a daily cron job to fetch the Jira status and at least email a diff? Still manual, but maybe less chaotic than Slack messages.

Oh yeah, that Slack notification trap is a real thing. It feels like progress because you've automated *something*, but you're just moving the manual check from one place (Jira) to another (Slack). I've seen it create a sort of alert fatigue where people just start ignoring the notifications.

The webhook idea is interesting, but I think you're right about them being for internal events. I had a similar hope with their Google Calendar sync - thought maybe I could catch an event there - but no dice.

Honestly, this API gap is pushing me to look at other tools for this specific workflow. It's a shame, because I really like Fellow for the meeting part.

I've seen teams try that cron job route, and it often just creates a "daily digest to ignore". You're right that it's less chaotic than constant Slack pings, but it still adds a manual reconciliation step.

Your deeper point about Fellow's webhooks is key: they're designed as an outbound notification system, not an integration pathway. That architecture choice really limits these workarounds.

Instead of a cron job, has your team considered a simple weekly "sync check" as part of your stand-up? It's low-tech, but it forces a regular review without building a brittle system.

You've already identified the core problem, the "one-way street." This isn't a bug, it's a strategic design choice to create vendor lock-in. By making the API write-limited, they're funnelling you toward their platform as the source of truth. If you could freely pull data back from Jira, you'd have less reason to stay inside Fellow to manage those tasks. Your "attempted workarounds" are just you fighting the architecture they built to keep you in their garden.

The real question you should be asking isn't about cron jobs or Slack workarounds. It's about what happens when your team gets tired of this and you need to move to a different meeting notes system. How do you extract that now-outdated action item data? The total cost here isn't just the lost engineering time, it's the eventual migration tax when you hit a wall with a closed ecosystem.

I just started testing this integration myself last week, and that exact gap is driving me nuts! I was so excited to finally connect our meeting notes to development work, but the one-way thing makes it feel half-baked.

You mentioned looking at Zapier - I did too, and hit the same API wall. It feels like Fellow is treating action items as static notes rather than living tasks. Have you found any other tools that handle this two-way sync better? I'm already overwhelmed just looking. 😅

Yeah, the cron job diff idea just creates stale data on a schedule. If the API won't let you write back, you're just building a fancy report of your broken process.

I've seen teams go down that road. Ends up being a daily email everyone filters to spam. You're right, it's less chaotic than Slack, but it's still a dead end.

Real fix is probably a custom middleware that uses the Jira webhook to *create* a new comment in the Fellow note via their API, pretending to be a user. Messy, but at least it's push, not pull. Still a hack against their walled garden.

Your custom middleware idea using Jira webhooks to create a comment is architecturally sound as a push-based notification, but it still introduces significant data integrity problems. The action item's core status remains static in Fellow, creating a state mismatch where the comment history says one thing and the actual task property says another.

I've built a similar proxy for a different tool, and the maintenance burden comes from mapping Jira's rich transition webhook payload to a plain text comment that's useful. You'll need to parse assignee changes, status transitions, and resolution details, then format a coherent update, all while avoiding comment spam on every minor ticket edit.

This approach also fails for bulk updates. If you move fifty tickets to 'Done' in Jira, you're triggering fifty separate API calls to create comments, which could hit rate limits and becomes noisy. The workaround starts to dictate your operational workflow.

> state mismatch where the comment history says one thing and the actual task property says another

Spot on. That's a huge UX red flag for any team member glancing at the action item. They see "In Progress" but have to read a comment from 5 days ago saying "Done". That's confusing and erodes trust in the system itself.

You're also right about the maintenance burden of mapping Jira's payload. I tried something similar with VWO's webhooks once, and the sheer number of possible field changes becomes a parsing nightmare. It's not a one-time setup; it's an ongoing maintenance chore every time Jira updates a field or your workflow changes.

The bulk update problem is the real kicker though. It turns a simple admin task in Jira into a potential API flood. Have you found a way to throttle or batch those calls, or does the workaround just fall apart at that scale?

Throttling calls just treats the symptom. The deeper problem is you're building a notification system for a data mismatch you created. It's alert fatigue all over again, but for your own middleware.

Every field mapping you write is technical debt against Fellow's next API change. What if they decide to rate-limit comment creation?

Your workaround doesn't just fall apart at scale, it actively obscures the real cost of staying on a one-way street.

Yeah, the "fancy report of your broken process" line really hit home. We tried a scheduled report for our sprint reviews, and it just became this extra step everyone dreaded.

But your custom middleware idea sounds like it swaps one manual check for another, just on the dev side now. Isn't that still a workaround that could break if Fellow changes something?

>Isn't that still a workaround that could break if Fellow changes something?

That's the whole point. Every workaround here is building on top of a brittle API. You're not swapping manual checks, you're just moving the fragility from the ops team's cron job to the dev team's middleware. It still breaks when the vendor sneezes.

You're just trading one kind of debt for another, with more moving parts.

Yeah, that exact limitation with the API is what makes it feel like a dead end. I tried building a small script to poll for updates, but if there's no endpoint to write status back, it's just a read-only dashboard.

Have you looked at whether their webhooks can at least notify when a linked Jira ticket changes? Even if you can't update the item, maybe you could post a comment in Fellow automatically? Not ideal, but better than nothing.

It's weird they'd build a one-way integration in 2024. Makes me wonder if it's a technical limitation or a business choice.