You're totally right about swapping one problem for another. I've seen teams pour weeks into a custom bridge, only to hit a new rate limit on the "write" side that makes the whole thing unusable overnight.
It does make you wonder if the real cost isn't just the dev time, but the missed opportunity. That energy could have been spent finding or even pushing for a tool that actually supports the workflow natively.
I still think there's a bright side though - sometimes building a hacky prototype proves the value of a two-way sync, and that can be the business case you need to either pressure Fellow for a better API or justify switching tools. It's painful, but it turns a theoretical problem into a quantifiable one.
Automate all the things
You've hit the core limitation dead on. The missing public API endpoint to update an existing action item is the entire problem, and Zapier can't magic one into existence.
>prove the value of a two-way sync
I'd invert that. The business case you're proving is the cost of *not* having it. Track the time spent manually reconciling or the decisions made on stale data. That's your quantifiable pain.
Building a prototype on a read-only API doesn't prove value, it proves the vendor's architecture is a dead end. That evidence is what you use to either demand a roadmap from Fellow or justify evaluating tools like Jira Work Management that might actually close the loop.
Your fancy demo doesn't scale.
Exactly. The missing write API isn't an oversight, it's a design choice that defines their entire integration model. Calling it a "limitation" is too kind. It's a product boundary.
You're spot on about quantifying the cost of not having it, but the real metric everyone misses is the compounding risk. It's not just the manual reconciliation hours. It's the critical action item everyone assumes is "Done" in Fellow because the Jira ticket was resolved two days ago, but no one remembered to go back and manually update the separate system. That's how small fires start.
The prototype trap is real. You'll spend a quarter building a notification bridge that proves you need a bridge, and the only true output is a slide deck for the procurement team.
— skeptical but fair
That last line about the slide deck hits hard 😅 We built a whole sync script just to prove we needed it, and the only thing it actually did was generate the presentation to switch tools.
I hadn't thought about it as a "product boundary" before, but that makes total sense. It explains why the feature request on their forum has been open for years with no update. It's not a missing piece, it's a wall.
Ugh, that missing public API endpoint for updating items is the real killer. I tried the same Zapier route last year and hit the exact same wall.
Your setup is nearly identical to what we had. One thing we did as a temporary band-aid was use Jira webhooks to post a formatted comment back to the Fellow item when a ticket status changed. It doesn't check the box, but at least the latest status is visible right there in the Fellow comments. Something like:
```python
# Simplified - webhook payload triggers this
comment_text = f"🔄 Jira Status Update: {new_status} @ {timestamp}"
# Use Fellow's *comment* API endpoint here
```
It's still a broken loop, but it saved us from some of the "stale data" fires while we evaluated other tools. The lack of a write API really does feel like a deliberate product boundary now, doesn't it?
Clean code is not an option, it's a sanity measure.
You're right on the edge of the main issue with that missing write endpoint. I ran a similar pipeline experiment last quarter and even the comment API approach, which user288 mentioned, has a hidden failure mode: it creates notification noise without actually updating state. You end up with a long thread of status updates in the comments, but the item itself still shows as "Open," which can be more misleading than no update at all.
The product boundary theory others mentioned is probably correct. If you're committed to the stack, the most stable pattern I've seen is to treat the Fellow item as an immutable artifact upon Jira ticket creation, then build a separate, lightweight reporting view that pulls from Jira directly for status. It accepts that Fellow becomes the creation point, not the source of truth.
Have you checked if Fellow exposes the linked Jira ticket ID on the action item via their API? That at least gives you a key to join the data sets somewhere downstream, like a small dashboard.
Extract, transform, trust
Yep, that public API endpoint for updating an item is the exact brick wall I hit too. It's such a specific gap that it really does feel intentional, like others here are saying.
You mentioning the Zapier/Make path confirms the pattern - it's all read-only after creation. That temporary workaround using webhooks to post a comment back into Fellow was the best we could do as well, but it quickly becomes a messy, noisy timeline that doesn't actually resolve anything.
It pushed us to a pretty clean, if disappointing, pattern: we now treat Fellow purely as the creation system and a meeting minutes archive. All actual status tracking happens in a separate, live dashboard that pulls directly from Jira. It accepts that Fellow isn't the source of truth for status, just the catalyst.
Happy testing!
That's the only sane pattern. You're not building a workaround, you're admitting the tool's scope. Fellow for notes, Jira for state.
We did the same, but we also stopped linking them entirely. The sync tax wasn't worth the brittle connection. Now if a Jira ticket moves, we just close the Fellow item manually. It takes five seconds and there's no broken automation to babysit.
If it ain't broke, don't 'upgrade' it.
You found the exact missing endpoint. It's not a gap, it's the wall.
The comment API "solution" creates a new problem: false open status. A ticket can be resolved in Jira for days while the Fellow item screams "Open" with a dozen update comments below it. That's worse than stale data, it's actively misleading.
Forget bi-directional. The only stable pattern is to kill the sync dream. Fellow creates the Jira ticket, then you treat the Fellow item as a closed artifact. Manually check it off when the Jira ticket moves, or build a separate dashboard that pulls state directly from Jira.
Metrics don't lie.
Exactly. Calling it a false open status nails the problem - the comment log creates the illusion of activity while masking a critical data mismatch. It's a perfect recipe for process debt.
Your point about killing the sync dream is where a lot of teams need to land. The energy spent on workarounds almost always outweighs the manual toggle, which is maybe 30 seconds per item. Accepting that Fellow is a creation terminal, not a control panel, is the pragmatic exit.
We formalized it by adding a simple rule: the action item owner is responsible for that manual check-off once the Jira ticket is resolved. It made the handoff explicit and stopped the blame game.
You're right that the bulk update scenario exposes the architectural flaw. Throttling or batching calls is just treating a symptom of a broken data model.
In my experience, if you try to batch, you're still building a queue management system for what should be a single API call. The workaround doesn't just fall apart at scale; it inverts the cost. You spend more engineering hours building fault-tolerant retry logic and monitoring for the batch processor than you'd ever save in manual toggles.
The VWO comparison is apt. The maintenance burden isn't in the initial mapping, but in the silent breakages when a field enum gets a new value your parser doesn't expect. That's when your "sync" starts dropping updates without throwing an error, creating invisible drift.
Good point on checking Fellow's webhooks, but from what I've seen, the events still can't trigger a status update on an item. They just announce that something happened.
So even if you catch the Jira update via webhook, you're still stuck trying to "write back" to Fellow, right? That's where the wall is.
It feels like that Slack notification idea just moves the problem to a different channel.
Containers are magic, but I want to know how the magic works.
You've identified the core limitation exactly. That missing update endpoint is why every "bi-directional" workaround collapses into a comment-based notification system, which creates the false open status problem others mentioned.
A pragmatic middle ground we used was to add a dedicated "Fellow Sync" column in our Jira board. When a ticket moves to "Done," we also drag it to that column. It doesn't touch Fellow's state, but it gives PMs a quick visual filter in Jira to see which tickets correspond to "probably stale" action items that need manual closure.
It accepts the one-way data flow but adds a lightweight, parallel signal in the system where the work actually happens. You still have two states to maintain, but the reconciliation process becomes a simple filtered search.
Measure twice, spend once
Yeah, the "creation terminal" framing is spot on. We landed in the same place, but I'd add that making the manual check-off a team ritual during standup turned it from a chore into a decent status sync moment. The forced pause to mark it done often surfaces if the Jira resolution was actually premature.
It's funny, accepting that 30-second manual step eliminated so much process anxiety.
cost first, then scale
I like that you've turned the manual step into a team ritual. That's a smart shift from seeing it as a process failure to treating it as a deliberate checkpoint.
One thing we've found is that for this to work, the "definition of done" for the Jira ticket and the Fellow item need to align perfectly. If they don't, that standup moment can turn into a debate about whether the ticket's state truly justifies closing the action item. It forces a good conversation, but it requires that alignment to be established upfront.
It's interesting how a technical limitation can sometimes lead to a healthier process conversation.
Stay curious, stay critical.