Office Hours #9Webhooks &Websockets
Sam demonstrated the difference between traditional polling and live websocket communication in Base44. Using a one-prompt Discord clone, he showed the conversion to Base44's new subscribe system in a single prompt — encountering and troubleshooting real-time rate limiting along the way.
From the top of the call
Three announcements
Merch design competition · Winner
Ben Stegles
- 22heart-emoji reactions
- 20+submissions in the running
- 250credits as the prize
Won with 22 Base44 heart emoji reactions (the most by far out of 20+ submissions). His entry stood out for its unique video format and the fact that he actually got the design printed as real merch. He receives 250 credits as the prize. Sam emphasised they wanted community-inspired originality, not just AI-generated designs. More competitions like this will run in the future.
"Design from URL" Feature Teased
John dropped a link to an X (Twitter) post about a "Design from URL" feature one minute into the session. Sam recommended everyone watch the video. This appears to be a new Base44 feature or upcoming capability.
Websockets/Subscribe Now Available
Base44's websocket implementation (internally referenced as "subscribe") is live and documented. Sam confirmed it works for live data syncing and demonstrated it converting an existing app in one prompt.
Deep dive · teaching sections 01–05
How the signals work
Six teaching sections came out of this session — the five mechanics below, then the sixth, the live Discord-clone conversion, told in full underneath.
What Are Webhooks?
Most modern apps can't afford to wait — webhooks solve the latency problem of polling.
Without webhooks: Data is logged to a database entity, then polled/pulled at intervals (typically 5–10 seconds). Messages appear in batches, not live.
With webhooks: Listeners and events create a closed-loop system where data appears instantly.
Three components required: a sender (app that detects the event), a receiver (app notified via webhook URL), and an event trigger (the action that sets it off).
Real-world examples: chat apps, stock trade alerts, system failure notifications, live weather updates, tickers.
Webhooks vs APIs vs Websockets
API = asking a friend "did anything happen?" (you request, they respond).
Webhook = your friend texting you whenever something happens (you don't ask — the message just arrives).
Websocket = two-way persistent connection (both sides can send/receive at any time).
It's not "websocket OR API" — APIs often leverage websockets internally. An API is how you integrate something pre-built; a websocket is how you allow that API to communicate live.
Webhooks are one-way; websockets are two-way.
A webhook is essentially a callback method where one system uses an API to instantly notify another system of an event.
When to Use Which
Webhook: Use for one-way notifications — e.g., getting live weather updates, receiving payment confirmations from a gateway.
Websocket: Use for two-way live communication — e.g., multiplayer games, live chat, collaborative editing.
Payment providers (like Stripe): the webhook/listener is on THEIR end, not yours. You're already in a request-response loop, so you don't need a live listener on your side.
Rate Limiting Considerations
Websockets DO get rate limited, but differently from standard Base44 rate limits (error 429).
The "X is typing" indicator is especially susceptible — if many users trigger it simultaneously, you'll hit throttle limits fast.
Fix: Include throttling instructions in your prompt — e.g., "ensure there is throttling on typing events so we don't run into rate limits."
Webhooks can actually help avoid 429 errors that occur with aggressive polling.
Other strategies: queue requests and batch them.
Implementation Advice
Websocket conversion should never be more than a one-prompt job.
The prompt pattern: "Please pivot from my old system to utilize websockets for [specific features]. Reference: subscribe [docs link]."
Always reference "subscribe" and link to the Base44 documentation — if you just say "implement websockets" the AI may try unsupported approaches.
If you encounter rate limits after conversion, follow up with a prompt specifying throttle requirements.
Control+F5 (hard refresh) fixes stuck publish buttons.
Deep dive · teaching section 06
Live Demo: Discord Clone Conversion
One Discord-style chat app, two transports. Sam built it with polling, then pivoted it to Base44’s subscribe system — in a single prompt.
Step 1: Built a simple Discord-like chat app WITHOUT websockets (one prompt). Used traditional polling — messages appeared with delay, in batches.
Step 2: Converted to websockets in ONE prompt using Base44's subscribe system.
The conversion took ~9 minutes to execute but was a single prompt.
After publishing, the chat was fully live — messages appeared instantly with typing indicators.
The "online status" indicator didn't fully convert (still used old HTTP polling), which would need a follow-up prompt.
“Please pivot this to utilizing websockets (subscribe) [link to Base44 subscribe docs]. So that communication appears instantly and we can see a 'display name is typing' or 'several people are typing' feature when people are typing at once. Ensure there is throttling on typing events so that we don't run into rate limits.”
One prompt · ~9 minutes to execute · fully live after publishing
Community Q&A
Four questions, answered live
4 questions answered during the live session.
Websockets are two-way — both sides can send and receive. Webhooks are one-way — you're pulling from something that's live. When you implement a webhook, you're pulling from a live source. When you implement a websocket, you're creating a looped two-way system.
Yes, websockets do get rate limited, as demonstrated live when the "several people are typing" indicator got throttled by everyone in the session triggering it at once. However, they don't get rate limited in the same way as standard Base44 rate limits. You need to implement throttling (e.g., on typing events) to manage this, and it's definitely viable for achieving live functionality.
You wouldn't set up a webhook for a payment provider — you'd set up an API. The listener/webhook is on the payment gateway's end, not yours. When a user makes a payment, you send the request to the gateway, which already has its own webhook listening for those requests. Since you're already in a natural request-response loop (send request → wait for response → proceed), you don't need a live listener on your side.
Stripe probably requires a two-way sync — it needs to send data back to your app live (e.g., payment confirmations, subscription updates). If Stripe requires a webhook, it means they need to push data to you and you need data from them in a persistent way. (Sam noted he doesn't know the Stripe documentation specifically but this is the likely reason.)
The recording
Watch the line open.
The full session as it streamed live — polling chat, the one-prompt subscribe conversion, and the rate-limit throttling fix, end to end on YouTube.
Play recordingOffice Hours #9 — Webhooks & WebsocketsYouTube · Recorded liveDebrief
What to carry out of session #9
Notable quotes
“Most modern apps can't afford to wait — and that's what webhooks solve.”
“An API is like asking a friend "did anything happen?" A webhook is your friend texting you whenever something happens. You don't ask — the message just arrives.”
Six takeaways
Always reference Base44's "subscribe" documentation when prompting for websocket implementation — don't just say "implement websockets" or the AI may try unsupported approaches.
Websocket conversion should be a one-prompt job: "Please pivot from my old system to utilize websockets for [feature]. Reference: subscribe [docs link]."
Rate limiting applies to websockets differently than standard polling, but you WILL hit it at scale — always include throttling instructions in your conversion prompt.
Ben Stegles won the merch design competition with 22 reactions — the community valued originality and effort over AI-generated designs.
Webhooks are one-way notifications; websockets are two-way persistent connections. Use webhooks for alerts, websockets for live collaboration.
Payment providers like Stripe handle the webhook/listener on their end — you don't need a live listener on your side for payment flows.