AI App Builder Webhooks (2026): Can Anything Actually Call Your App?

Quick answer (September 2026). Every AI app builder can send an HTTP request out. The question that actually separates them is whether something on the internet can call your app at a URL you control, run your code, and get a reply. On that axis the eight builders split three ways. Replit, v0 by Vercel, Lovable and Bolt.new give you an arbitrary server-side endpoint. Bubble and Softr give you a generated endpoint behind a switch you have to find, and Softr puts it on a paid tier. Base44 and Webflow each have two different answers depending on which half of the product you are standing in, and in both cases the half you land on by default is the one that cannot do it.

That last point is the finding worth the read, and it is the one nothing on the first page of Google currently says.

The category confusion this question keeps falling into

Search for webhooks and an app builder together and you get three kinds of page, none of which is this one.

You get products named "App Builder" that are not the category at all, such as Adobe Commerce App Builder. You get webhook builders, tools whose job is to generate a webhook for you. And you get automation platforms such as Make and Zapier, which are in the business of sending webhooks to your app.

All three are the inverse of the practical question. If you are choosing an AI app builder, you are not shopping for a tool that emits webhooks. You want to know whether the app the builder generates can stand still at a fixed address and be called by Stripe, GitHub, Twilio, or your own back office, at three in the morning, without you being awake.

The decision order

Inbound is not one capability. It is four, and they fail independently.

1. Is there a URL? Something has to be addressable from outside.
2. Does your code run when it is hit? An address that maps to a static page is not an endpoint.
3. Is it reachable when nobody is using the app? Webhooks arrive on the sender's schedule, not yours.
4. Can you verify it? An open endpoint that accepts anything is a liability, not an integration.

Most feature tables answer only the first. The differences live in the other three.

Where the eight builders land, September 2026

Every cell is sourced to the vendor's own documentation, read on 16 September 2026. Links are in Sources.

The two-tier trap

Base44 and Webflow both give you a different answer depending on which surface you are on, and in both cases the default surface is the weaker one.

Base44. If you follow the app editor into automations, inbound events come from connector automations, and those are an allowlist. The documented list is Gmail, Google Calendar, Google Drive, Microsoft OneDrive, Outlook, SharePoint, Teams, Slack, and Wix. That is a productivity-suite list plus the company's own parent. Stripe is not on it. Neither is GitHub, Twilio, nor Shopify. If you read only that page you would conclude Base44 cannot take a payment webhook.

It can. Base44's backend functions are a separate mechanism, and each deployed function gets its own HTTP endpoint at https://{your-app-domain}/functions/{function-name}. Base44's developer docs name the case directly: "Webhooks: Receive callbacks from external services like Stripe or GitHub." So the honest description is not that Base44 is limited. It is that Base44 has a no-code inbound path that is allowlisted and a code inbound path that is not, and nothing in the app editor tells you the second one exists.

The catch on the code path is worth knowing before you ship: when a function is called over direct HTTP rather than from the frontend SDK, there is no authenticated user, so every data operation has to run as a service role. Backend functions also cap at five minutes of execution.

Webflow. Webflow's Data API webhooks are entirely outbound. Webflow sends a POST to a URL you nominate when something happens on your site, with x-webflow-timestamp and x-webflow-signature headers. There is no mechanism there for Webflow to receive a webhook and run your code, because classic Webflow gives you no server-side runtime.

Webflow Cloud is a different product. It deploys Next.js, Astro, Vite or static apps onto a Cloudflare Workers runtime, with SQLite, a key value store, and object storage. A framework app there can absolutely expose a route that receives a POST. Two constraints are documented and both matter for webhooks: worker CPU time caps at 30 seconds per request, and Node.js support is partial, with the docs advising that if you are migrating you "pay close attention to API routes, authentication, and third-party libraries". Partial Node compatibility is not an abstract concern when your signature verification depends on a crypto library.

The thing that silently breaks: availability

Point three of the decision order is where most people get hurt, because it fails weeks after launch rather than on day one.

Senders retry, then give up. A webhook endpoint that returns errors for long enough gets disabled at the sender's end, and the first you hear of it is a support ticket about missing orders.

• Lovable states plainly that edge functions are unavailable while a project is paused, and features depending on them stop working until you resume. A paused Lovable project is a silently dead webhook endpoint.
• Replit defaults to Autoscale, which "scales to zero when idle". That is fine for webhooks, because a request wakes it, but it is a cold start on a sender that may be impatient. Replit's Reserved VM is the documented answer for "always-on API servers" and bots, at a fixed monthly cost.
• v0 by Vercel also scales to zero, with fluid compute explicitly there to reduce cold starts.

Scaling to zero and being paused look similar on a status page and are completely different for an integration. One wakes up. The other does not.

Verification, which nobody puts in the comparison

An inbound endpoint you cannot authenticate is an open write to your database.

Bubble has the most granular published model. The Workflow API has to be enabled in Settings, each workflow has to be explicitly exposed, and authentication is then set per workflow to one of three levels: None required, User and admin, or Admin only. Bubble's own guidance is that "None required" is the typical choice for public-facing workflows, which is exactly the setting a webhook needs, and exactly the setting that leaves signature checking entirely to you.

Webflow supplies signatures on the sending side, with one trap: webhooks created through the Webflow dashboard "will not include the request headers needed to validate request signatures". The convenient path silently produces unverifiable deliveries. Only webhooks created through the API carry them.

Everywhere else, verification is code you write, and it needs somewhere safe to keep a signing secret. That is not a detail you can defer, and it is the point where this criterion collides with how each builder stores secrets.

What to check before you commit

• Ask for the URL, not the feature. "Supports webhooks" is satisfied by outbound. Ask to see the address something else would POST to.
• Find the plan gate separately from the feature. Softr's webhook trigger is real and sits on Professional or higher. The feature existing and the feature being available to you are different questions.
• Check what happens when the app is idle. Paused, sleeping, and scaled-to-zero are three different states with three different outcomes.
• Decide where the signing secret lives before you write the handler.
• If payments are the reason you are asking, read the money path first. A payment webhook is only as useful as your control over what the builder does with payments.

Verdict, September 2026

If inbound webhooks are load-bearing for your product, Replit and v0 by Vercel impose the fewest constraints, because in both cases you are deploying an ordinary server-side route and nobody has opinions about which services may call it. On Replit, choose the deployment type deliberately rather than accepting the default.

Bolt.new is the strongest of the managed options on documentation alone. It is the only builder in this group whose docs list "receiving webhooks from third-party services like Stripe or GitHub" as a headline use case for its server functions, which means the path is supported rather than merely possible.

Bubble is the pick if the endpoint needs real access control and you would rather configure that than code it.

Lovable works and is the one to watch operationally, because pausing a project takes the endpoint down.

Softr is fine if you are on Professional or above, and a non-starter below it.

Base44 can do this, through backend functions rather than through the automations UI most users will find first.

Webflow is a genuine split: classic Webflow sends webhooks and does not receive them, Webflow Cloud receives them like any Workers app.

The general lesson is that this criterion is not a yes or no. It is a question about which product surface you happen to be standing on, and the default surface is frequently not the capable one.

Limitations

This compares what each vendor documents publicly as of 16 September 2026. Where a capability is not described, that is an absence in the documentation rather than a proven absence in the product, and it is recorded that way throughout. No plan prices appear here deliberately, because prices move and plan gates are the durable part. Retry behaviour, delivery guarantees and per-endpoint rate limits are not compared, because the eight vendors do not document them at a comparable level of detail and a table built on that would be misleading.

A note on the outbound direction

The opening claim that outbound is easy everywhere deserves one qualification, because on one builder it is easy in a specific and limited shape.

On Replit, v0, Bolt.new, Lovable and Base44, outbound is just an HTTP call from server-side code, so there is nothing to compare. Bubble has the API Connector. Webflow's Data API is outbound by design.

Softr is the exception worth naming. Its outbound mechanism, Call API, sends a POST, PUT, PATCH or DELETE to any REST API or webhook endpoint, and the docs are clear that it is attached to buttons: available on buttons in list blocks and list details blocks, not on topbar buttons. That is a genuinely useful escape hatch for integrating services Softr has no native connector for, and it is user-triggered by construction. If you need Softr to call something without a person clicking, you are back to its Workflows, and the trigger types there are the ones listed above.

So the accurate version is that outbound is unconstrained wherever you have server-side code, and shaped by the product everywhere you do not.