> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superoffice.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How to use links in docs

> How to format links to pages, headings, external sites, and downloadable files, including reference-style links.

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:

```markdown theme={null}
[link to Google!](http://google.com)
```

## Link text

Use either the title of the page you are linking to or a friendly, descriptive label.

<Note>
  Don't use "click here" or . It is bad for SEO and blinds the reader.
</Note>

## 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](#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.

<Note>
  **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.
</Note>

### 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.

### HTML href links

`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](#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.

## Reference-style links

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:**

```markdown theme={null}
[Markdown guide](./markdown-guide/index)
```

**After:**

Inline text:

```markdown theme={null}
[Markdown guide][1]
```

Link references at the end of the file:

```markdown theme={null}
[1]: ./markdown-guide/index
```

Make sure that you include the space after the colon, before the link. Otherwise, the link will be broken.

<h2 id="anchors">
  Bookmark links (anchors)
</h2>

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.

```markdown theme={null}
[Integer datatype](#integer-datatype)
```

**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.

```markdown theme={null}
[Integer datatype](../datatypes#integer-datatype)
```

**Add anchor:**

Use Mintlify's [custom heading ID][1] syntax: append `{#anchor-label}` to the heading line. The label must be lowercase and not contain spaces.

```markdown theme={null}
## Heading text {#anchor-label}
```

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.

<Note>
  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.
</Note>

## Link to download a file

1. Place the file to be downloaded in the *downloads* folder at the repository root.
2. Format the link like this:

   ```markdown theme={null}
   <a href="/downloads/FILE" download>LINKTEXT</a>
   ```

   Don't use reference-style links for downloads.

<Note>
  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.
</Note>

## xref (cross reference) links

Currently not supported for SuperOfficeDocs.

[1]: https://www.mintlify.com/docs/create/text#custom-heading-ids
