Partner widget probe

Travelpayouts script tag. Marker 755680 is ours, so clicks attribute correctly. Athens, Travelpayouts city id 99239.

Loader is the real b2b-nemo-prod bundle, now with defer — see the result note for why that one attribute is the whole fix. data-partner-id="omiolps" per Omio's own instruction; attribution rides on data-redirect, not on this field.

RETRACTED, 2026-09-06: this box used to say data-partner-id="7679741" was tested, did not render, and must never be retried. That conclusion was wrong. It renders. So does omiolps. So would anything — the field cannot block a render, because it is an optional passthrough that becomes one hidden input on the search form.

The real cause was our own <script> tag. The bundle scans for div[data-omio-widget="true"] once, at execution, with no DOMContentLoaded and no observer. Ours sat above the div, so it scanned an empty document. Adding defer fixes it.

Why it fooled us: a null result reads as unambiguous, so it invites no follow-up question — but only if the instrument could have produced the other answer. This one could not. Nothing about the id was ever under test.

Attribution, settled with the mechanism visible: Omio confirmed clicks attribute via the tracking link, and the form bears that out — redirect is posted as its own field carrying 3963000, which is also confirmed current. request_partner_id is separate and is Omio's internal handle.

Written before the device run, so the answer cannot be fitted to the result.
· Renders in the WebView → remote scripts run, and Omio joins Tiqets as answered.
· Does not render, but Tiqets does → not a WebView-script problem; suspect the api.omio.com position lookup, which is a fetch the WebView may treat differently.
· Neither renders → remote scripts do not run in the WebView, and every script-tag widget is dead. That is the finding the whole probe exists for.
· Tapping Search — the form is target="_blank" POSTing to api.omio.com. System browser is fine; navigating away inside Kovalo with no way back is the outcome that stops all three partners shipping, regardless of how they render.

BLOCKED: our partner_secret note says the stored key is “service role only — never expose to the client”, but Ferryhopper’s own embed puts the widget key in client-side JavaScript. Both cannot be true, and guessing wrong publishes a credential. Needs the Affiliate Dashboard checked for which key type this is.

Their widget is a custom element, not an iframe — so it is the same “does a remote script run” question as the other two, plus a custom-element registration.

<script> /* fhiw loader, per widgets.ferryhopper.com */ </script>
<script>fhiw('client', '<WIDGET API KEY — see blocker above>');</script>
<ferryhopper-widget origin="PIR" destination="JTR"></ferryhopper-widget>
<!-- PIR = Piraeus (Athens), JTR = Santorini -->