Access to subAddress Property of Hyperlinks in Powerpoint Javascript API

We are running into a hard blocker with the current PowerPoint JavaScript API: there is no way to create, read, validate, or repair internal slide targets for hyperlinks. We can set address and screenTip, but we cannot set the equivalent of SubAddress, and we cannot produce the internal slide jump action that PowerPoint uses (ppaction://hlinksldjump backed by a relationship to a slide part). This is straightforward in VBA, and it is a core building block for any automated in-slide navigation.

Our real-world use case is in-slide navigation bars for long client reports. Each tab should jump to another slide in the same deck. Decks are living documents, so slides are constantly inserted, deleted, and reordered. Without internal link target support, links drift silently over time and there is no safe way for our add-in to do “one button” validation and repair. Even if we do not need the links to function inside PowerPoint, we do need them to survive “Save As PDF” so the navigation works in the distributed PDF, and that still requires true internal targets when authoring the PPTX.

As of now, we are considering a workaround that is objectively the wrong direction: download the PPTX from SharePoint, unzip the package, inject the a:hlinkClick actions and relationships ourselves, repackage it, then upload it back to the original location. That breaks normal authoring workflow and introduces serious operational risk. It effectively forces a “publish step” because we cannot safely overwrite a file that is being coauthored. Even a 20 to 30 second round trip can conflict with live edits and trigger refresh prompts, conflicts, or lost updates. It turns a simple user-initiated “refresh nav links” into a brittle external pipeline with locking, versioning, retries, and conflict handling. It is hard to support across teams because it requires governance and process discipline rather than letting the add-in update the deck in-session where coauthoring and AutoSave are designed to work.

What we need is a first-class way to target slides internally from Office.js:

• Add subAddress support for PowerPoint hyperlinks (read and write), or provide a dedicated internal target API like linkToSlide(slideId) or targetSlideId.
• Support reading the internal target of existing links so we can validate and repair decks created from templates.
• Prefer stable identifiers (slideId) over slide index or display text, since slide order changes frequently.
• Ensure parity across Windows, Mac, and Web so a task pane add-in can be truly self-sufficient.

This would unlock a large category of automation that PowerPoint users expect: agenda tabs, section navigation, template-driven cross-linking, hyperlink validation and repair, and reliable PDF-export navigation, without forcing VBA, VSTO, or risky Open XML rewrite workflows.