Reduce access for manual synchronisation + more sync frequency options

Ideas & Features
1

I’ve just set up a space to synchronise shopify orders into Fibery so we can manage our orders from within Fibery. Upon setting access for the warehouse staff I discovered a few challenges:

  1. The minimum sync frequency is 1 hourly
  2. Manual Sync can only be initiated by a user with Architect privileges with architect mode toggled on

Unfortunately the warehouse can’t really afford to wait an hour to get new orders coming through, but we would rather like to work in Fibery as universally as we can.

So I created a new space with Architect permissions and then came into a new issue - I can’t migrate the existing integration to a new space. So now we’re stuck in the position that I’ve had to enable Architect level permissions to a space which contains multiple integrations so the warehouse person can have up to date orders to process.

The following would solve these problems (which I suspect are fairly frequent for new users):

  • 5 minute sync frequency as a palatable wait for many real time workflows
  • Manual sync for non-architects
  • Offering migration of integrations to another space

The last point was also discussed here:
Move integration to another space
What is the best way to move integrations to a new space?

Keep up the wonderful work :blush:

2

Is this a custom integration? If so, you could possibly add webhooks support so that updates will be near instantaneous.

3

That hadn’t occurred to me! I wonder if that would be possible with Fibery hosted integrations or whether they would need to be hosted by us.

4

It’s definitely possible with a custom integration you host yourself. If you’ve built the integration in Fibery using AI, then webhooks are not yet supported I’m afraid.

5

+1 for higher sync frequency

Webhooks are possible but they create a huge amount of complexity for the integration.

With a 5 minute delta sync you’ve now with no additional effort made the integration almost “real-time”. There are so many things I have to work around because Fibery is not “real-time” with my core dbs. It would mean I can use Fibery more often as the source and build Custom Apps on top of real-time external data :exploding_head:

And now we have a dashboard to track our “Integration syncs” and can pay for Extras :slight_smile:

6

Since this discussion pops up in both ChatGPT and Manus for this topic… I’ll chime in with the feature request I just submitted… it includes the cases here…

Name of app or file format and URL:

Supabase — real-time / bidirectional integration

Use case:

We are building an immersive, participatory storytelling platform that crosses AI experiences (including ChatGPT), live events, community activities, media, wearables, and in-person experiences.

We would like to use Fibery as the business-user control plane for the live experience, while Supabase serves as the production backend for player/user accounts, session state, interactions, research data, and other runtime data.

For our use case, periodic synchronization would not be sufficient. We need authorized nontechnical operators in Fibery to be able to make certain changes and have them reflected in the live product immediately or near-immediately, without waiting for a scheduled sync or requiring a developer deployment.

Examples include:

  • publishing or updating story/world content, lore, prompts, activities, and configuration;

  • changing content or configuration in an active projection-screen display/app, game, or immersive theater experience while participants are using it;

  • opening, closing, replacing, or modifying participant research/data-collection questions;

  • viewing relevant live player/session state and correcting an individual participant’s state when something goes wrong;

  • pausing or changing a broken experience affecting an active group;

  • publishing time-sensitive announcements or interventions;

  • seeing whether a change successfully reached the production system;

  • versioning and rolling back changes quickly when necessary.

The operational environment makes latency especially important. Some experiences will run at live conferences and in-person community events, where organizers may have paying participants physically waiting while they diagnose and correct an experience. “Change it now and know that it worked” is a core requirement, not just a convenience.

We do not necessarily need every piece of high-volume product telemetry copied into Fibery in real time. Supabase can remain the source of truth for production/runtime data. What we need is a reliable real-time path for the subset of data and commands that business users need to observe and operate the live experience from Fibery.

Ideally, the integration would support:

Fibery → Supabase
Real-time create/update actions or explicit publish/command actions, with success/failure confirmation.

Supabase → Fibery
Real-time or event-driven updates for selected records/events that require human visibility or intervention.

Operational safety
Stable IDs, relationships, timestamps, version information, permissions, error reporting, and enough support for rollback/audit history that operators can safely make live changes.

The larger reason we’re requesting this integration is organizational: we want developers to build the underlying product capabilities and integration contracts once, while writers, researchers, producers, community organizers, and other business users can operate and evolve the experience without requiring engineering work for every content, configuration, research, or live-operations change.

Traditional CRM/customer-support integrations such as Zendesk or Intercom do not fit this use case. We aren’t primarily managing support tickets. We’re managing the continuity and operation of a live participatory world in which story state, AI interactions, participant state, research, real-world events, and human interventions can affect one another.

A native Supabase integration with strong real-time/event-driven support would make Fibery substantially more viable as the operational workspace for this kind of product.

7

If you don’t mind me asking, why are you choosing this tech stack? Could you not build a frontend for Supabase and bypass the need for Fibery?
Or could you not use Fibery on its own (with native databases eliminating the need for Supabase)?

8

I agree with you mate that 1 hour sync is too long for order processing. A 5 10 minute option would be much more practical and allowing non Architect users to trigger a manual sync would solve the access issue without giving them unnecessary permissions. Being able to move an existing integration between spaces would also make the setup much easier.

9

I agree that this is a big issue. Not having a near-instant sync from Github is kind of a dealbreaker for using Fibery as an issue tracker in a team. I’m in too deep now, so I’ll probably end up writing a custom integration or hacking around triggering a sync through a webhook. But had I known that this is how the sync works, I probably never would have tried Fibery to begin with.

10

Well, first I’ll qualify that I haven’t touched code or databases in 8 years. I do have 2 tech cofounders, but both are from big IT backgrounds… so they don’t know how to answer this.

My reason for Supabase + Fibery: Supabase will handle the consumer / attendee experience. Fibery will have to handle all the admin and support flow experience, plus live ops during events.

My reason for not skipping Fibery and just using Supabase… I want the support, admin, and live ops pieces to be customizable by business users without the need for dev support or AI dev in lovable that touches WAY too much to do one little thing and throws everything off.

11

OH NO… Really? Dammit. What would you have used instead of Fibery? ClickUp? Plane? Linear?

12

If I’m honest, I think maybe Fibery isn’t the best tool for this job. The integrations in Fibery are almost entirely read-only, whereas you need a simple front-end to Supabase with update capabilities.
Have you considered something like softr.io?
(or retool, uibakery …)

13

I think there is a lot to unpack here.

I literally signed up to Fibery ten minutes ago. But how I discovered Fibery, and how I want to use it, are two different business questions.

I’ve had ideas incubating around Supabase + Twenty v2.0 CRM as part of a broader operational platform. My AI knows that architecture, so naturally I’m comparing Fibery against it.

When I read that @bikesupplies is actually using Fibery in production and needs five-minute synchronisation rather than hourly, I would have expected the answer to be something like “yes, that’s on the roadmap”, “we’re evaluating it”, or even “no, here’s why that isn’t part of our product direction”.

Instead, the answer seems to be to build and host a custom integration. nathan_jay then rightly points out the additional complexity that introduces.

And I think @pebblebypebble gets to the heart of the opportunity: Fibery as a control plane where business users can evolve their operational experience without requiring engineering work for every change.

Then the discussion effectively ends six weeks ago with Chr1sG suggesting another product that isn’t Fibery.

That gives me weird vibes.

You have to realise that people reading these threads are prospective customers trying to understand what Fibery can replace, not engineers looking for instructions on how to build around its limitations.

I’m trying to consolidate my tools into fewer monthly subscriptions, not add more. I’m simultaneously researching whether Fibery can replace Notion, whether it could eventually replace Linear, how it integrates with Supabase, whether I can use ChatGPT through MCP to create and manipulate whiteboards, and what its AI-generated Custom Apps can actually do. All while watching your onboarding videos and trying to understand the product.

And now, before I’ve even decided whether to purchase Fibery, I’m researching Softr, only to discover that its native Supabase integration requires a Professional plan costing US$119/month on monthly billing.

That’s rather the opposite of what attracted me to Fibery in the first place.

I’m about to start a new role as an AI Operations Lead. Part of that role is identifying opportunities to simplify how a business operates, how people and AI agents work together, and how nontechnical staff can adapt processes without depending on developers for every little change.

That’s what makes Fibery interesting to me.

I understand that Supabase is a production backend, and that Fibery isn’t necessarily designed to replace it. I’m also not suggesting five-minute polling magically solves bidirectional synchronisation or live transactional consistency.

But I want to understand the intended boundary of your platform.

If Fibery owns the operational data, how far can I take its native databases, automations, Custom Apps and AI agents before needing specialist development?

If another platform owns the production data, does Fibery intend to offer a supported, near-real-time operational control layer over that data? Can business users safely initiate changes, receive confirmations and handle exceptions without commissioning a custom integration for each workflow?

And regarding the original request: are faster synchronisation, non-Architect manual sync and integration portability on the roadmap, deliberately out of scope, or simply not prioritised?

I’m not looking for a commitment to build everything. A clear explanation of what Fibery wants to be—and what it explicitly doesn’t want to be—would be genuinely useful.

Because the exciting proposition isn’t that I can connect another ten applications. It’s that Fibery might let me stop needing ten applications in the first place.

That’s the product I’m here to evaluate.

14

Let me try to answer, and I will be happy to dig deeper, so please don’t hesitate to ask

  1. Fibery owns the data, we do not use any third-party platforms to host it (well, AWS we do use)
  2. Technically it is possible to have 5-mins sync, but we can’t offer it for free in all plans since it can be very compute-heavy. Some alleviations are web-hooks and delta-syncs. If connector supports them, then syncs are relatively cheap. However imagine that for some connector you try to fetch 100K records every 5 mins — this can be heavy. So we might add short sync in enterprise plan. Right now Gmail/Email connector has 5 mins sync, for example.
  3. Right now we are working (and soon release) custom integrations where you can build them really fast. They are hosted on Vercel and here we may allow to have shorter sync time (but it costs money, so we may sell it via credits, we are thinking about it now)
    Screenshot 2026-10-13 at 2.10.02 PM
    Screenshot 2026-10-13 at 2.10.02 PM1920×1102 231 KB
15

Hi @AdamP,
Happy to hear that you decided to give Fibery a try. I will try to address the points you raised; feel free to follow up if you have more questions/feedback.

As @mdubakov has written, it is in the backlog, but there are some caveats, and currently no ETA. It was my bad that I didn’t state this up front, before diving into suggestions to solve the problem in the here-and-now.

We do hope that Fibery can serve as the primary OS for companies, without needing engineering work for every change, but at the same time, we find that Fibery appeals to (and works well for) people who are naturally ‘tinkerers’. We position ourselves as suitable for orgs run by nerds(!)

When we offer help to people, whether here in the community or in chats/calls, we will always try to be honest about Fibery’s strengths and weaknesses, and we will definitely suggest alternatives (competitors even) when we think they will give the user a better experience. We don’t want to talk people into using Fibery with empty promises about what it can do.
Based on @pebblebypebble’s summary of what they needed, it definitely sounded like Fibery’s lack of bidirectional integrations would be a showstopper, which is why I suggested alternatives.

Well, Fibery can often replace Supabase as the production backend, in which case, the polling interval is irrelevant, since Fibery ‘owns the data’.

I will let other Fibery users offer input on how far you can take Fibery, but IMHO there are very few limits on what you can achieve, and now with AI there is generally no reason to need specialists.

Almost certainly not, if ‘operational control’ and ‘initiate change’ means making updates to that third-party data. Fibery native integration syncs are almost entirely one-way.

faster sync - planned (see Michael’s post) but no eta
non-architect manual sync / integration portability - in the backlog, but unlikely to happen any time soon (= not currently prioritised)

Have you read this:

?

Fibery aims to be the central operations tool for companies, providing a reliable backend with foundational functionality (data storage with relations, collaboration, notifications, history, permissions, automations/formulas, etc.) and a usable front end, plus support for custom UIs when needed.

For use cases where Fibery doesn’t yet work v well, e.g. helpdesk, sw version control, payment processing, etc. Fibery aims to integrate with existing tools (Intercom, Github/Gitlab, Braintree, etc.) so that the data from these tools are surfaced in the Fibery workspace.

Hope some of this helps … :crossed_fingers: