Realtime data refresh in UI Bakery for incoming calls (Supabase + webhook)

[canary]

Hi @Kate,

I’m looking for the best way to handle a realtime call-center–style workflow.

Context:
An external phone system can send a webhook whenever a new incoming call starts.
That webhook creates or updates a record in Supabase (phone number, caller details, call ID, timestamps, etc.).

What I want to achieve:
As soon as an incoming call is received:

• the caller’s details should become instantly visible in the UI Bakery app

• the UI should automatically focus/select that phone number or call record

• the user should be able to start adding notes immediately while the call is ongoing

• no manual refresh or page reload

In other words:

Incoming call → webhook → Supabase update → UI Bakery updates in realtime

I’m aiming for instant or near-instant updates, similar to a softphone or CRM call screen.

Would it be possible to create such an app inside UI Bakery?

Any advice or examples would be very helpful. Thanks!

PS. This is not the only usecase for me, I also want to use realtime data refresh for other apps.

I already searched inside the docs but could not find docs about realtime data refresh.

[Kate]

Hi @canary

There are three main approaches to real-time updates in a web app:

1. Polling (short interval)
   The frontend periodically calls an API / database (e.g., every 0.5–2 seconds) to check for changes.
   This approach can be configured directly using UI Bakery actions (for example, interval-based data reload + UI updates).
2. Supabase Realtime (Broadcast or DB changes)
   The server or database publishes real-time events into a Supabase channel.
   The frontend subscribes to that channel and receives updates instantly via WebSockets.
   In UI Bakery, this requires a custom component (React) or custom JavaScript logic embedded in the app.
3. Own WebSocket connection
   You run and manage your own WebSocket (or Socket.IO) server.
   The frontend connects directly to it for real-time events.
   In UI Bakery, this also requires a custom component or custom JavaScript integration.

[canary]

Thanks for sharing some approaches, @Kate.

In our case, events come from external systems (e.g. Make could send data via an HTTP request to a webhook URL).

Would it be possible (or is it on the roadmap) for UI Bakery to offer a built-in, beginner-friendly webhook option, for example:

• UI Bakery provides a webhook URL

• when that webhook receives data from Make via an HTTP request, the app can automatically:

  • refetch queries

  • update app state

  • or focus/select a specific record

• all configurable via actions, without custom JS or custom React components

This would make event-driven use cases (incoming calls, CRM updates, external triggers) much easier to implement in a true low-code way.

Why this could be valuable for UI Bakery:

• It lowers the entry barrier for non-technical users (like me) who struggle with WebSockets, Supabase Realtime, or custom React components.

• It aligns perfectly with the low-code promise: event-driven behavior without writing JavaScript.

• Many popular tools (Make, Zapier, phone systems, CRMs) already speak “webhooks”, making integrations much easier out of the box.

• It enables common business use cases (incoming calls, live CRM updates, notifications) with minimal setup.

• Compared to polling, it’s more efficient, scalable, and cost-friendly — especially as apps grow.

From a positioning standpoint, this could help UI Bakery attract more teams who want real-time behavior without complexity.

I’m curious if something like this is being considered.

[Kate]

Thanks for the detailed explanation. This is a very valid and well-thought-out use case.
Today in UI Bakery, we can expose a webhook via Automations, so external systems (Make, Zapier, phone systems) can send HTTP events. However, Automations are backend-only and are not connected to a live UI session in the browser.
Because of that:

• A webhook cannot directly trigger UI actions.

• It can’t refetch queries, update UI state, or focus/select records on its own.

So even if a webhook receives data, the frontend still needs a way to “notice” the change. This means one of these is still required:

1. polling via UI Bakery actions

2. a realtime layer (Supabase Realtime / Broadcast)

3. a custom WebSocket connection

What you’re describing: webhook → UI actions without any client-side realtime mechanism, would require UI Bakery to maintain its own realtime channel between backend and UI sessions and expose it in a low-code way. We agree this would significantly lower the entry barrier and fits very well with event-driven use cases.
At the moment, this exact capability isn’t available, and this is something we don’t have in our plans to develop.
For now, the recommended options remain polling (simplest), Supabase Realtime, or a custom WebSocket, depending on the level of real-time needed.

[canary]

Thanks for the clarification. That makes sense.

@Kate

What you’re describing: webhook → UI actions without any client-side realtime mechanism, would require UI Bakery to maintain its own realtime channel between backend and UI sessions and expose it in a low-code way. We agree this would significantly lower the entry barrier and fits very well with event-driven use cases.

This part really captures the core of the solution.

From a low-code perspective, all current options come with clear trade-offs:

• custom WebSocket → most complex and least accessible

• Supabase Realtime → powerful, but still quite technical for many low-code users

• polling → simple, but suboptimal in terms of scalability, cost, and efficiency

This makes it hard for non-technical teams to implement truly event-driven UI behavior in a clean way today.

Would it make sense to create a feature request for a built-in, event-driven webhook → UI update capability, to gauge how many users run into this limitation?

My suspicion is that this is a broader adoption blocker for non-technical teams familiar with Zapier or Make, particularly for low-code use cases like incoming or outgoing calls, CRM updates, or other use cases that require UI Bakery to stay open and react in real time.

Thanks again for the openness and transparency.