In Appium, what does POST /session/:sessionId/url do in a native Android or iOS session?

## The route, and why it is not a mobile invention `POST /session/:sessionId/url` is WebDriver's own navigation command — the one a browser session uses to go to a page. Appium's mobile drivers did not invent a parallel route for deep links; they answer this one. From a native session on either platform, sending a URL to it means "hand this URL to the device and let the system route it", which is exactly deep-link entry. Two notational points are worth getting right, because they surface in every discussion of this route: - The path segment is spelled `:sessionId`. That is how it appears in the sources. - The body is JSON carrying `url`. There is no second key for a target application. ## What each platform does with it | | Android | Apple platforms | |---|---|---| | driver | UiAutomator2 | XCUITest | | what the OS is asked for | an `android.intent.action.VIEW` intent carrying the URL | the URL opened by its registered handler | | how the driver reaches the OS | `adb` on the host | `simctl` on a Simulator, WebDriverAgent on a real device | | who decides the receiving app | the system's own intent resolution | the system's registered scheme handler | The important line is the last one. Because the route's body carries only `url`, nothing in the request names an application. On both platforms the operating system makes that choice, using whatever happens to be installed on that particular device. That is fine for a custom scheme only your app claims, and genuinely risky for an `https` URL. ## Route versus execute method Both spellings reach the same behaviour, so the choice is about how much control you need. 1. `POST /session/:sessionId/url` — terse, protocol-standard, one key in the body, no way to name a target. 2. `mobile: deepLink` on `POST /session/:sessionId/execute/sync` — a parameter map that also names the receiving app: `package` on Android, `bundleId` on Apple platforms, plus Android's `waitForLaunch`. A short decision rule: - If exactly one installed application can claim the scheme, either spelling works and the route is the shorter one. - If the URL is an `https` link, or a second app registers the same scheme, use the execute method so the target is explicit. - If you need Android's `waitForLaunch` behaviour, the execute method is the only place it exists. - If a client wrapper already exposes navigation as a first-class call, the route may simply read better in your suite. ## What the route does not do - It does not wait for your destination screen; it returns once the device has been given the URL. - It does not report which application ended up handling the URL. - It does not install anything: the target app must already be on the device. - It carries no target argument, so it cannot resolve an ambiguous URL for you. Each of those is a place where a suite goes quietly wrong rather than failing loudly. The characteristic symptom is a find that times out on a screen looking nothing like the one the test expected, because a different application answered the URL. ## Reading it in a log When you are staring at a server log, this route is easy to overlook precisely because it looks like ordinary browser navigation. On a native mobile session it is not navigation of a page at all — it is a request to the operating system, and everything after it depends on how that system resolved the URL. Reading it that way turns a confusing trace into an obvious one: the request succeeded, the URL was delivered, and the next question worth asking is which application received it, not whether the command worked. ## Saying it well A strong answer names the route with its real spelling, says that both mobile drivers answer it from a native session as deep-link entry, gives the two mechanisms — a view intent on Android, the URL handed to the OS through `simctl` or WebDriverAgent on Apple platforms — and then draws the distinction that matters day to day: the route has no argument for the receiving app, and `mobile: deepLink` does.