Google Maps link being rewritten → “Invalid Dynamic Link” error (need guidance)

Joel M

Aug '25 • 🐛 Questions

We send our clinic address with a Google Maps link in both SMS and chat. Users intermittently seeing:

> **Invalid Dynamic Link**

> Requested URL must be a parseable URI, but possibly incomplete to be a DynamicLink.

**What we want:**

Users tap the link and open Google Maps. No rewriting, no shorteners.

**Current setup (templated):**

```jinja

# Global & Tasks now use a single source of truth:

# Voice (send via SMS as plain text – no brackets/quotes):

Google Maps: {{ custom_values.google_map_link }}

# Chat (show as plain text – no markdown):

🗺️ Google Maps: {{ custom_values.google_map_link }}

```

**Example value (works when pasted directly):**

```

https://maps.app.goo.gl/bwci7qdTEcoBuCZG6

```

**What have we already tried:**

1. Removed all markdown formatting (`[]()`), quotes, and any rich-text wrappers.

2. Stopped using any `map_short` or hardcoded links; everything resolves from `{{ custom_values.google_map_link }}`.

3. Added explicit notes to keep **link shorteners/tracking OFF** in the send path.

4. Ensured the URL is emitted as **plain text only** (no extra characters before/after).

5. Verified consistent behavior across EN/ES and Voice/SMS/FB/IG templates.

**Symptoms now:**

* Some recipients still get a rewritten link that fails with the “Invalid Dynamic Link” message.

* It looks like something in the pipeline may be auto-converting or wrapping the `maps.app.goo.gl` URL.

**Questions for the group:**

* Is there a known setting in Assistable (or common SMS/FB connectors) that **forces link rewriting** or applies a **Dynamic Links / link-shim** layer?

* Is `maps.app.goo.gl` specifically prone to being rewritten? Would you recommend using a canonical Maps URL instead (e.g., `https://www.google.com/maps?q=<encoded address>` or `https://www.google.com/maps/search/?api=1&query=<encoded>`), and does that avoid rewriting?

* Any way to **force “no tracking/rewriting”** at the message level in Assistable?

* Are there best practices for emitting the link so gateways don’t wrap it (e.g., prefixing with `http://` vs `https://`, adding “Google Maps:” before the URL, or avoiding emojis on the same line)?

**Extra info:**

* The plain-text URL works if we paste it into a browser/SMS manually.

* The error appears only after the message goes through our Assistable → channel pipeline.

Thanks in advance for any pointers or known gotchas!

1 comment