What the current contract says

Notion’s external file object accepts a publicly accessible HTTPS URL and returns that URL as supplied. The documentation does not state that a query string makes the URL invalid.

Test setup

We used a private synthetic Notion page and entered two public HTTPS image URLs: one with a single query parameter and one with two parameters. After the editor accepted each URL, the page still contained the complete value, including ?, &, parameter names, and values.

Tested steps

  1. Enter an HTTPS image URL ending in ?synthetic=1.
  2. Confirm the complete URL remains in the page.
  3. Repeat with a different URL ending in ?synthetic=2&size=large.
  4. Confirm the second complete URL remains in the page.
  5. Compare the observed round trip with Notion’s current external-file documentation.

Both URL strings were preserved exactly. This narrows the diagnosis: a query string alone is not enough to explain an external-image failure.

What to check next

Confirm that the final URL is public over HTTPS, remains stable, and returns image content without cookies or authorization. Inspect redirects and expiry behavior. Finally, verify that the JSON request contains the unmodified URL in the documented external.url field rather than a hand-built or partially encoded payload.

Evidence boundary

This test did not submit an authenticated image-block request or prove that either URL renders as an API-created image block. It only establishes UI preservation plus the documented API contract. A live API reproduction is still required to attribute a specific failure to reachability, response behavior, or client serialization.