Skip to main content
This section describes how to use links from pages hosted at docs.superoffice.com. We differentiate between links to content on the same page, links to neighboring pages, and links to external websites and URLs.

​
Format

Type the link text in square brackets directly followed by the URL in parentheses. Format: [Link text](url) Example:

​
Link text

Use either the title of the page you are linking to or a friendly, descriptive label.
Don’t use “click here” or . It is bad for SEO and blinds the reader.

​
Links from one page to another

Two different things carry a link target in this repo: markdown links ([text](path), used in regular body content) and HTML href values (<a href="path">, and the href prop on components like <Card>). This section covers markdown links. See HTML href links below for what’s different about the other kind.
  • Use forward-slash (/) in paths.
  • Omit the file extension (.md or .mdx): link to page, not page.md or page.mdx.
Link to another page in the same folder: [link text](./page) Link to a page in the parent folder: [link text](../page) Link to a page in a sub-folder: [link text](./folder/page) Link to a page in a subfolder of the parent folder: [link text](../folder/page) Relative paths like these are the right default as long as both pages stay within the same main topic: the whole en/developer-portal/ tree, the whole de/company/ tree, this whole contribute/ tree, and so on. Two patterns worth naming directly:
  • The parent folder’s own landing page is ../index: the same “page in the parent folder” pattern above, just naming its index.
  • A self-contained generated reference tree (en/database/tables/, the archive-provider/MDO-provider reference) stays relative by its own generator’s convention: see the note below.
Link to an absolute path beginning at the root of the repository: [link text](/folder/page) Use this root-relative form only when the link crosses a topic or language boundary: for example, linking from en/company into en/integrations or release-notes, or a Swedish page linking to English-only content. Why the split: within one topic, the same relative link text is correct in every translated copy of that topic: learn/create means the same thing whether it’s written on en/company/index.mdx or (once translated) da/company/index.mdx. A root-relative link would have to change per language (/en/company/... vs /da/company/...), which is one more thing a translation can get subtly wrong. And within a small, single-language tree like contribute/, prefixing every link with /contribute just adds length without adding safety. Once a link leaves its own topic or crosses a language boundary, there’s no parallel copy to stay in sync with, so the extra length of a root-relative path is worth it for the unambiguous target, and it’s what mint broken-links and Mintlify’s production build check against.
Exception: en/database/tables/ is generated by an external pipeline outside this repo and deliberately kept on relative sibling links (for example, ./associate). Moving those files would require changing that pipeline regardless of link style, so don’t convert this folder’s internal links to root-relative.

​
Amendment: “topic” isn’t always one top-level folder

The Guides tab (the translated User Guide) is authored as a single cohesive topic that spans many top-level en/ folders, because each folder is really a subsection of the same translated whole, not an independent topic. A link between any two of those folders stays relative, the same way en/company linking into en/company/learn would. Root-relative only kicks in when a Guides-tab page links somewhere genuinely outside that whole set: en/api/, en/developer-portal/, integrations/, release-notes/, and similar siblings. When judging whether a link is “in topic,” check against the whole-tab set, not just the immediate folder name. href values follow the same relative-vs-root-relative rule as markdown links above, with two additions:
  • Downloads are always root-relative. The downloads folder is a single shared location at the repository root, not part of any topic tree: see Link to download a file below.
  • Watch the index.mdx resolution gotcha. Raw <a>/Card hrefs show up most often on landing/index pages (built from HTML block elements rather than a markdown list). A relative href on an index.mdx file resolves against the folder containing that file, so learn/create written on company/index.mdx means company/learn/create, not company/index/learn/create. Same resolution rule as any other page, but easiest to get wrong here since landing pages so often link to their own child pages.
  • mode: "custom" category-landing index.mdx pages always use root-relative hrefs, regardless of topic locality. This overrides the relative-within-topic rule above for these specific files (company/index.mdx, sale/index.mdx, learn/index.mdx, and the rest of the Guides-tab hub pages, in every language). Don’t convert their hrefs to relative even when linking within the same topic.
We use reference-style links to make the source content easier to read and maintain. You move the (long) URLs, or paths, to the end of the file and reference them by labels in square brackets. This applies to internal links as well as external URLs. Before:
After: Inline text:
Link references at the end of the file:
Make sure that you include the space after the colon, before the link. Otherwise, the link will be broken.

​
Bookmark links (anchors)

Bookmark links go to a specific heading on the current or another page. Link to heading in the current file:
  • Use a hash symbol (#) followed by the lowercase words of the heading.
  • Remove any punctuation and replace spaces with dashes.
Link to a heading on another page:
  • Use whichever link form (relative or root-relative, per the rule above) that page would normally get, plus a hash symbol (#), followed by the lowercase words of the heading.
  • Remove any punctuation and replace spaces with dashes.
Add anchor: Use Mintlify’s custom heading ID syntax: append {#anchor-label} to the heading line. The label must be lowercase and not contain spaces.
This only applies to headings. The older <a id="anchor-label"></a>/<a name="anchor-label"></a> pattern still renders (Mintlify passes raw HTML through) but is discouraged on headings going forward: it leaves a heading with two IDs (the explicit one and Mintlify’s own auto-generated slug of the heading text) instead of the single canonical ID {#anchor-label} produces. The <a id> pattern is still the only option for an anchor target that isn’t a heading (for example, a point inside a <Tab> or an <Update> block): keep using it there.
On translated pages, always add an explicit anchor to any heading you link to from elsewhere - the ID has to stay identical across languages (for example, #fields on both the English and German version of a page) even though the heading text itself is translated, and Mintlify’s auto-generated slug is derived from that translated text so it can’t serve that role. On untranslated content, add an explicit anchor only when the heading is long, hard to write/remember, or expected to change - otherwise rely on the bookmark links Mintlify generates automatically from the heading text.
  1. Place the file to be downloaded in the downloads folder at the repository root.
  2. Format the link like this:
    Don’t use reference-style links for downloads.
Certain file types don’t play well when the user tries to download from a browser. Please ZIP files available for download to ensure they can be downloaded.
Currently not supported for SuperOfficeDocs.