# Can Adalo Web View detect postMessage or URL changes?

Confirm what Adalo's native Web View can report back to an app, then choose a webhook, return link, status check, or custom component for an embedded widget.

- Canonical URL: https://adalocado.com/answers/adalo-webview-postmessage-url-change
- Verification: Documented from current sources
- Topic: APIs and Integrations
- Skill level: Advanced
- Last reviewed: 2026-09-30
- Builder and evidence scope: Current Adalo Webview, HTML Renderer, Marketplace, component developer, and roadmap documentation reviewed September 2026; no native iOS or Android build was reproduced by the editorial team
- Verification owner: Erin Heart and Ana Morgan
- Next review: 2026-12-30
- Index status: index-now

## Short answer

Treat Adalo's stock Web View as display-only: as of September 30, 2026, it has no documented postMessage or URL-change action. For Stripe, Calendly, and similar embeds, use a provider webhook to update a status record, then let Adalo check it after a return link or Done button. Build a custom component only when live browser events are essential.

## Intended outcome

A supportable integration plan that does not mistake an iframe message or success redirect for authoritative completion and still gives native users a clear return path.

The practical dividing line is whether the browser event is merely useful or is the only proof that something happened. If a provider has a webhook or status API, let that server-side signal update the record and make the app a reader of the result. If the provider exposes only a JavaScript event, the stock Web View is the wrong boundary: a custom component must receive, validate, and deliberately export that event into Adalo.

## Requirements

- The provider's documentation for redirects, webhooks, API status, and embedded JavaScript events
- A real test account for the third-party widget
- A decision about whether completion must be immediate or can be confirmed after a short return step
- A server-side endpoint or automation when using webhooks
- A published deep link or an in-app Done or Refresh button for the return experience
- Real iOS and Android test builds
- A React and React Native developer if a custom component is required

## Step by step

1. **List every completion signal the provider offers**

   Check for a signed webhook, a status API, success and cancel redirect URLs, and a JavaScript event. Record which signals are server-authenticated and which exist only in the browser. Do not begin with the embed code alone.

2. **Use the server signal when one exists**

   For Stripe, listen for the appropriate Checkout event. For Calendly, subscribe to invitee.created and invitee.canceled. Let the provider notify a server endpoint and verify the request according to that provider's documentation.

3. **Create a pending session before opening the widget**

   Create an Integration Session tied to the logged-in user and the Order or Booking. Give it a random public correlation key and save the provider object ID when available. Start it as pending.

4. **Open the hosted experience**

   Use the provider's hosted page in an external or in-app browser when that is supported. Use the stock Web View only when the page permits embedding and no event needs to cross into Adalo during the session.

5. **Update status from the backend**

   When the verified webhook arrives, match it by provider object ID or correlation key, process it idempotently, and update the authoritative Order or Booking plus the Integration Session. Keep Adalo API keys and provider secrets on the server.

6. **Give the user a return path**

   Use a provider success URL that reaches an Adalo deep link when the provider supports it, or show a clear I've finished button after the browser closes. That button should check status; it should not mark the operation successful by itself.

7. **Use a custom component only for a real event requirement**

   If the integration is JavaScript-only, build a cross-platform component that owns the Webview, listens for native onMessage and navigation changes, and exposes Adalo action props with typed arguments. A wrapper page you control can validate iframe message origins and relay only the allowed event.

8. **Test interruption and replay**

   Repeat the flow with cancellation, back navigation, delayed webhooks, duplicate webhooks, app backgrounding, process termination, and no network. A completed server record must recover the correct state even if the browser event never reaches the app.

## Why it works

- The stock Web View and Adalo's action layer are separate unless the component explicitly exports an action or value. A page can call window.postMessage—or window.ReactNativeWebView.postMessage in a compatible React Native host—but nothing reaches Adalo when the host component does not listen and expose the result.
- The HTML Renderer is more than plain text: it renders supported HTML, media, and iframes and exposes On Link Pressed. Its security model strips script tags and inline event handlers, so it cannot act as a general host for a scripted widget bridge.
- A success URL, postMessage event, or tap on Done is a user-interface signal. It can improve navigation, but it can be forged, lost, delivered twice, or missed when the app is suspended. A signed provider webhook or a server-side status query is the safer source of truth.
- A custom Adalo component can connect browser events to the app because Adalo's developer API lets a component call configured actions and pass arguments into Magic Text. The component still needs separate web and native behavior and must validate the sender, payload, and session before exposing an event.

## Which workaround should you choose?

Choose webhook plus status check when the provider offers a server callback. This is the best default for payments, bookings, signatures, and other operations that matter after the browser closes. Add a deep link or Done button for convenience, not correctness.

Choose redirect matching only when the provider offers success and cancel URLs and the result is low risk—or when a custom component can intercept the redirect while the backend independently confirms completion. Choose a custom component when the provider exposes only JavaScript events or when an immediate in-app action is essential.

## What a custom bridge needs to do

On native iOS and Android, the component owns a React Native WebView and handles its message and navigation callbacks. It then calls an Adalo action prop with safe text arguments such as event type, session key, and a sanitized result. On web, it needs a separate iframe or web implementation and a window message listener.

If the third-party widget lives in an iframe inside a wrapper page, the wrapper should allowlist the widget origin, check the payload, and relay only known events to the native host. Never accept every origin, pass through arbitrary commands, or treat a client message as payment proof.

## Stripe and Calendly examples

For Stripe Checkout, create the Checkout Session on a server, associate it with the Order or Integration Session, and listen for Checkout completion and delayed-payment events. Stripe explicitly warns that fulfillment based only on the landing-page redirect is unreliable. After the user returns, Adalo reads the backend status.

For Calendly, subscribe to invitee.created and invitee.canceled, then update the matching Booking. The embedded scheduler can stay a presentation layer. A Done button can refresh the Booking after the widget closes, and a delayed webhook can leave the screen in a truthful pending state until confirmation arrives.

For native payments, integration architecture is only half the decision. Adalo's current Stripe guidance says Stripe is for physical products or services in native apps; digital products or services require an in-app purchase path.

## Roadmap status

There is a public feature request titled Make action when URL in Webview changes. It dates to February 2021 and is currently labeled open. That confirms the use case is known, but it is not evidence of a scheduled release.

No public Adalo source reviewed for this answer announces native postMessage listening or gives a delivery date for URL-change actions. Build against today's documented behavior and recheck the Webview documentation and roadmap before each release.

## What changed since the video

- The current native Webview documentation still describes only a URL field and does not document an On Message Received or On URL Change action.
- The newer HTML Renderer can fire an On Link Pressed action, but it strips script tags and inline event handlers, so it is not a general JavaScript event bridge.
- The migrated roadmap includes an open URL-change action request dating to 2021, with no public delivery date or commitment shown.
- Adalo's component developer documentation does support action props, action arguments, and component data, which makes a purpose-built bridge technically possible as a custom component.

## Data model

| Collection | Properties | Relationships |
| --- | --- | --- |
| Integration Sessions | Public correlation key, provider, provider object ID, status, result summary, created time, updated time, and processed-event ID; never store provider secrets in client-readable fields | Each session belongs to one User and optionally one Order, Booking, or other business record |
| Orders or Bookings | Amount or event type, authoritative status, provider reference, completed time, and failure or cancellation reason | Belongs to one User and can have one or more Integration Sessions for retries |

## Common failures

### The embedded page sends postMessage but Adalo does nothing

That is expected with the stock Web View. Move the completion logic to a provider webhook or replace the stock component with a tested custom component that owns the Webview and exposes an Adalo action.

### The provider redirects, but the Adalo screen does not change

A redirect inside the stock Web View remains web navigation. Prefer an external or in-app browser plus an Adalo deep link, or use a custom component that intercepts the allowed success URL and calls a configured action.

### The deep link opens inside the Webview

Do not use the deep link as proof of success. Put a normal HTTPS confirmation page at the provider return URL, rely on the webhook to save status, and give the user a button to return to or refresh the app.

### The user taps Done before the webhook arrives

Keep the session pending, show a clear processing state, and let the user retry the status check. Do not convert pending to complete on the client.

### A duplicate webhook creates two orders or bookings

Store the provider event ID or object ID and make processing idempotent. Repeated delivery should return success without applying the business change twice.

### A marketplace component looks promising

Ask for its exact event contract, current update date, source of support, and a demo in published iOS and Android builds. Confirm whether it handles postMessage, top-level navigation, iframe messages, or only URL text matching; those are different capabilities.

### Stripe Checkout works technically but the store review fails

Check what is being sold. Adalo's current guidance limits Stripe in native apps to physical goods or services and directs digital goods or services to in-app purchase components.

### A Calendly booking completes but the app still shows pending

Confirm the webhook subscription includes invitee.created, that its scope covers the correct user or organization, and that the booking can be correlated to the pending Adalo user or session.

## Testing checklist

- [ ] The stock Web View is tested in real iOS and Android builds without assuming that browser Preview represents native behavior.
- [ ] A pending integration record belongs to the logged-in user and cannot be completed by changing a client-visible URL or message payload.
- [ ] A valid provider webhook changes the matching record from pending to complete exactly once, even when the event is delivered more than once.
- [ ] Closing the checkout or scheduling page before completion leaves the record pending or canceled and does not unlock the success path.
- [ ] The return flow works after the app is backgrounded, killed, or reopened, without depending on an in-memory postMessage event.
- [ ] A custom component accepts messages only from an allowlisted origin and rejects malformed, unexpected, replayed, or wrong-session payloads.
- [ ] Success, cancellation, provider error, delayed webhook, and no-network states are tested separately on both native platforms.
- [ ] Any native payment flow is checked against the current Apple and Google rules for the exact product or service being sold.
- [ ] The stock Web View is not expected to expose browser events
- [ ] The provider's webhook or status API is the authoritative source when available
- [ ] Every launch creates a unique pending session tied to the correct user
- [ ] No provider secret or Adalo API key is exposed to the embedded page or app data
- [ ] A redirect or client message never marks a payment or booking complete by itself
- [ ] The user has a clear return, refresh, pending, cancellation, and error experience
- [ ] Custom message handling checks event origin, event type, session key, and payload shape
- [ ] Published iOS and Android builds pass interrupted and duplicate-event tests
- [ ] The payment method follows current app-store rules for the item being sold

## Limitations

- Adalo's current Webview page documents URL input but does not explicitly publish a sentence saying that postMessage and URL-change events are unsupported; the conclusion comes from the documented controls, the still-open request, and the absence of an exposed action.
- The editorial team did not inspect every private component or every listing visible inside every Adalo account, so this page cannot prove that no third-party developer offers a private bridge.
- The historical Better WebView report is not evidence of a currently maintained marketplace component and does not demonstrate window.postMessage support.
- A webhook or redirect is available only when the embedded provider offers it, and some provider webhook features require a paid plan.
- Deep links provide a route back into the app but do not prove that the external operation succeeded and do not guarantee that an embedded Webview will close itself.
- A custom bridge must be implemented, maintained, and tested separately for web, iOS, and Android; provider pages may also block framing or change their event contract.
- The Adalo Collections API is currently limited to Team and Business plans; an external backend or supported automation may be needed on other plans.

## Screenshot evidence

These are captures of public documentation or forum reports, not proof of hands-on builder reproduction.

![Adalo Webview documentation showing only the Webview URL configuration methods](https://adalocado.com/evidence/official-webview-component.png)

Adalo's current Webview setup documents a URL entered directly or supplied with Magic Text; it does not show a message or navigation event action.

[Official documentation](https://help.adalo.com/component-basics/simple-components/webview-component) · captured 2026-09-30

## Community evidence

### [Native Web View: catch postMessage or detect URL changes?](https://forum.adalo.com/t/native-web-view-any-way-to-catch-postmessage-or-detect-url-changes-from-an-embedded-iframe-widget/70191)

A maker asks whether the native Web View can pass postMessage events or navigation changes into Adalo, and whether a current marketplace bridge or roadmap commitment exists. Boundary: The thread had no replies when this page was reviewed, so it documents the use case rather than confirming platform behavior.

### [Make action when URL in Webview changes](https://forum.adalo.com/t/make-action-when-url-in-webview-changes/64918)

The public roadmap contains a feature request for running an Adalo action when Webview navigation changes, including OAuth completion flows. Boundary: The request is still labeled open; an open request is not a scheduled feature or release commitment.

### [Better Deep Linking payment return](https://forum.adalo.com/t/better-deep-linking/20225?page=2)

A maker reported a working payment-return flow with PragmaFlow's Better WebView by matching unique text in success and failure redirect URLs and navigating to Adalo screens. Boundary: This report is old, covers URL matching rather than window.postMessage, and does not prove that the component is currently maintained or available.

### [PragmaFlow Better Web View maintenance warning](https://forum.adalo.com/t/playsinline-through-web-view/39430)

A community reply says PragmaFlow had stopped working on Adalo and suggests contacting the developer directly about Better Web View. Boundary: This is a community maintenance report, not an official marketplace removal notice or a current compatibility test.

## Sources

- [Adalo forum: native Web View postMessage and URL-change question](https://forum.adalo.com/t/native-web-view-any-way-to-catch-postmessage-or-detect-url-changes-from-an-embedded-iframe-widget/70191)
- [Adalo: Webview Component](https://help.adalo.com/component-basics/simple-components/webview-component)
- [Adalo: HTML Renderer](https://help.adalo.com/component-basics/marketplace-components/html-renderer)
- [Adalo: Marketplace Components](https://help.adalo.com/component-basics/marketplace-components)
- [Adalo Developers: Component Actions](https://developers.adalo.com/docs/interactions/actions/)
- [Adalo Developers: Component Data](https://developers.adalo.com/docs/interactions/component-data/)
- [Adalo Developers: Cross-Platform Compatibility](https://developers.adalo.com/docs/workflow/cross-platform/)
- [Adalo roadmap: action when Webview URL changes](https://forum.adalo.com/t/make-action-when-url-in-webview-changes/64918)
- [Adalo forum: historical Better WebView payment-return example](https://forum.adalo.com/t/better-deep-linking/20225?page=2)
- [Adalo: Set Up Deep Linking](https://help.adalo.com/component-basics/inserting-and-editing-screens/deep-linking/setup-deep-linking)
- [Adalo: Collections API](https://help.adalo.com/integrations/the-adalo-api/collections)
- [Adalo: Stripe](https://help.adalo.com/component-basics/marketplace-components/stripe)
- [Stripe: Handle post-payment events](https://docs.stripe.com/payments/existing-customers?platform=web&ui=stripe-hosted)
- [Calendly: Create a webhook subscription](https://developer.calendly.com/docs/api-guides/receive-data-from-scheduled-events-in-real-time-with-webhook-subscriptions)

## Changelog

- 2026-09-30: Published a source-backed answer and implementation decision tree for native Webview events, provider callbacks, and custom bridges.

## Related resources

- [What happens when an Adalo deep link opens without the app?](https://adalocado.com/guides/adalo-deep-link-fallbacks)
- [Can Adalo update an app built on another platform?](https://adalocado.com/answers/adalo-update-app-built-another-platform)
- [How does conditional visibility work in Adalo?](https://adalocado.com/answers/conditional-visibility)

Markdown version: https://adalocado.com/answers/adalo-webview-postmessage-url-change.md