fix: Changes all relative links to absolute (#23)

docs/concepts/access-controls.mdx

@@ -7,7 +7,7 @@ import { Alert, Alerts } from "@site/src/components/shared/Alert";
 
 # Access Controls
 
-Basis Theory secures sensitive data as [Tokens](./what-are-tokens) that are stored within an isolated
+Basis Theory secures sensitive data as [Tokens](/docs/concepts/what-are-tokens) that are stored within an isolated
 compliant environment, called a [Tenant](#what-are-tenants).
 Your systems interact with Tokens or Services (e.g. Proxy, Reactors) through the Basis Theory API using an API key that is issued to
 an [Application](#what-are-applications).
@@ -18,7 +18,7 @@ to ensure services and users only have access to the data they need.
 ## What are Tenants?
 
 Everything starts with a Tenant in your Basis Theory account. Tenants represent an isolated environment in which your
-[Tokens](./what-are-tokens) and other resources are defined, managed, and stored.
+[Tokens](/docs/concepts/what-are-tokens) and other resources are defined, managed, and stored.
 Data is not shared between Tenants, but you're allowed to create as many Tenants as you'd like within Basis Theory.
 You can use multiple Tenants to isolate different domains of data, and to support your Software Development Life Cycle (SDLC).
 
@@ -82,7 +82,7 @@ For basic authorization scenarios, an Application can simply be granted one or m
 Each Application Type allows a different set of permissions, and you can find a detailed list of them [here](/docs/api/applications/permissions#permission-types).
 
 Token permissions granted to Private or Public applications are applied to all Tokens
-(i.e. they are not scoped to a particular [Container](./what-are-containers) of Tokens).
+(i.e. they are not scoped to a particular [Container](/docs/concepts/what-are-containers) of Tokens).
 In order to ensure sensitive data is not inadvertently revealed by an Application, an implicit
 [transform](#transform) is applied for each operation:
 
@@ -143,9 +143,9 @@ Application to satisfy your specific requirements by choosing the `Create Your O
 #### Grant Multiple Systems Access Following the Principle of Least Privilege
 
 A common use-case for Applications is to grant minimal access to multiple systems where each system is only authorized
-to perform necessary operations and access a relevant subset of data within a [Tenant](./access-controls#what-are-tenants).
+to perform necessary operations and access a relevant subset of data within a [Tenant](/docs/concepts/access-controls#what-are-tenants).
 This could mean that one system is only allowed to collect Tokenized data, another system is allowed to read the data to
-perform analytics, and a third system is only allowed to [Proxy](./what-is-the-proxy/) the data
+perform analytics, and a third system is only allowed to [Proxy](/docs/concepts/what-is-the-proxy/) the data
 to an integrated 3rd party but never access the raw data.
 
 ![Applications Each System](/img/concepts/access_rules_by_customer.png)
@@ -156,7 +156,7 @@ Often, businesses need to grant their partners access to their sensitive data 
 traditionally, these businesses would just export the needed data and send it to their partner.
 With Basis Theory Applications, a business can create an Application that is restricted to ONLY the data that partner needs.
 In some cases, businesses will not allow their partners direct access to the raw data,
-but rather only allow them to [Proxy](./what-is-the-proxy/) the data to
+but rather only allow them to [Proxy](/docs/concepts/what-is-the-proxy/) the data to
 another API or execute serverless workloads on the sensitive data using Reactors.
 
 ![Applications Partners](/img/concepts/applications_partners.png)
@@ -193,7 +193,7 @@ A short description of the rule to help you identify its purpose.
 ### Container
 
 Access Rules can be scoped to a specific set of Tokens using Containers.
-[Containers](./what-are-containers) are a Token attribute that enable you to logically
+[Containers](/docs/concepts/what-are-containers) are a Token attribute that enable you to logically
 organize Tokens into hierarchical paths, similar to a UNIX directory structure.
 
 Permissions granted on a Container are inherited on all sub-Containers. For example, having an Access Rule
@@ -248,7 +248,7 @@ Rules are evaluated in ascending priority order, with the lowest numerical value
 #### Grant Access to a Single Data Classification
 
 Access Rules can be scoped to a specific data classification of Tokens. To enable this use case, first ensure your
-Tokens are organized into classification-based [Containers](./what-are-containers),
+Tokens are organized into classification-based [Containers](/docs/concepts/what-are-containers),
 for example `/pci/`, `/pii/`, and `/general/`.
 
 ![Access Rules](/img/concepts/access_rules_by_classification.png)
@@ -257,7 +257,7 @@ for example `/pci/`, `/pii/`, and `/general/`.
 
 Your customers' sensitive data can be partitioned within Basis Theory, for example, to enable you to offer your
 customers single-tenant environments that only have access to a single customer's data.
-To enable this use case, first ensure your Tokens are organized into [Containers](./what-are-containers)
+To enable this use case, first ensure your Tokens are organized into [Containers](/docs/concepts/what-are-containers)
 by customer, for example `/customer-1/`, `/customer-2/`, etc.
 
 ![Access Rules](/img/concepts/access_rules_by_customer.png)

docs/concepts/what-are-containers.mdx

@@ -7,7 +7,7 @@ sidebar_label: Token Containers
 
 Tokens can be logically grouped into Containers to segment Tokens within a Tenant.
 Containers can be leveraged to construct fine-grained access control policies by attaching one or more
-[Access Rules](./access-controls) to an Application.
+[Access Rules](/docs/concepts/access-controls) to an Application.
 Each Access Rule can be scoped to a specific Container of tokens, allowing you to grant an Application
 permission to interact with only a subset of tokens within your Tenant.
 

docs/concepts/what-are-mats.mdx

@@ -3,7 +3,7 @@ title: What are Monthly Active Tokens?
 sidebar_label: Monthly Active Tokens
 ---
 
-import { Alert, Alerts } from "@site/src/components/shared/Alert";
+import { Alert } from "@site/src/components/shared/Alert";
 
 # What are Monthly Active Tokens?
 
@@ -13,7 +13,7 @@ We will also explore how MATs are used to determine your monthly Basis Theory in
 
 ## How are MATs defined?
 
-A MAT is any [token](./what-are-tokens) that has been interacted with in a given calendar month via one of the following operations:
+A MAT is any [token](/docs/concepts/what-are-tokens) that has been interacted with in a given calendar month via one of the following operations:
 
 ### Create
 
@@ -35,7 +35,7 @@ Tokens that match your search criteria that are contained within other non-fetch
 
 ### Use
 
-Any token that is used within a [Reactor](./what-are-reactors) or the [Proxy](./what-is-the-proxy) will be counted as a MAT.
+Any token that is used within a [Reactor](/docs/concepts/what-are-reactors) or the [Proxy](/docs/concepts/what-is-the-proxy) will be counted as a MAT.
 This includes any tokens that were [Detokenized](/docs/expressions/detokenization) within a Reactor or Proxy request.
 
 <Alert>
@@ -46,7 +46,7 @@ This includes any tokens that were [Detokenized](/docs/expressions/detokenizatio
 
 ## How are MATs counted?
 
-MATs are counted separately per [Tenant](./access-controls#what-are-tenants) and are not aggregated across your Tenants.
+MATs are counted separately per [Tenant](/docs/concepts/access-controls#what-are-tenants) and are not aggregated across your Tenants.
 If you own more than one Basis Theory Tenant, e.g. for multiple environments to support your SDLC process,
 then each tenant accrues MATs and billing charges according to its own usage.
 

docs/concepts/what-are-reactors.mdx

@@ -80,7 +80,7 @@ curl "https://api.basistheory.com/reactors" \
 
 Reactors may be invoked by an Application with `token:use` permission, which enables the Reactor to detokenize tokens
 provided in the request `args`. It is recommended that you restrict which tokens a Reactor can detokenize
-by only granting `token:use` permission on the most-specific [container](./what-are-containers)
+by only granting `token:use` permission on the most-specific [container](/docs/concepts/what-are-containers)
 of tokens that is required.
 
 ```bash showLineNumbers

docs/concepts/what-are-tokens.mdx

@@ -145,13 +145,13 @@ A scenario where masking is useful is in enabling customer service representativ
 
 ### Containers
 
-[Containers](./what-are-containers) enable you to logically group Tokens and segment data within a Tenant,
+[Containers](/docs/concepts/what-are-containers) enable you to logically group Tokens and segment data within a Tenant,
 enabling you to organize Tokens based on your unique data governance strategy. By default, tokens are placed into
 containers based on [NIST defined](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf#page=6) data classifications
 and impact levels.
 
 Containers allow you to grant scoped access to subsets of Tokens, limiting the amount of
-data accessible by your internal systems. [Access Controls](./access-controls) can be used in conjunction with
+data accessible by your internal systems. [Access Controls](/docs/concepts/access-controls) can be used in conjunction with
 Containers to allow some systems access to highly confidential data while restricting access to only masked or redacted
 Tokens from other systems.
 

docs/concepts/what-is-search.mdx

@@ -93,7 +93,7 @@ additional Lucene features, please [let us know](mailto:support@basistheory.com?
 
 ### What is the difference between Search and Fingerprints?
 
-[Fingerprints](./what-are-tokens#fingerprinting) are a measure of uniqueness,
+[Fingerprints](/docs/concepts/what-are-tokens#fingerprinting) are a measure of uniqueness,
 not a representation of the underlying data. Fingerprints can be used to locate duplicate data, for instance, but do not
 allow you to find _specific_ data. You cannot find a card number ending in `4242` with fingerprints.
 

docs/concepts/what-is-the-proxy.mdx

@@ -25,7 +25,7 @@ For this reason, we require the destination servers to support TLSv1.2+ and that
 
 The application that is being used to call the Proxy must be granted `token:use` permission on any tokens that are detokenized.
 It is recommended that you restrict which tokens the Proxy can detokenize by only granting `token:use`
-permission on the most-specific [container](./what-are-containers) of tokens that is required.
+permission on the most-specific [container](/docs/concepts/what-are-containers) of tokens that is required.
 
 Whatever the content type or HTTP method, any HTTP request can be sent through the proxy simply by adding the headers `BT-API-KEY` and `BT-PROXY-URL`. For example:
 

docs/expressions/aliasing.mdx

@@ -41,8 +41,8 @@ dynamically evaluated expression, and can be provided within the `id` property o
 You are able to reference the `data` property within an [object](/docs/expressions#language-objects) expression -
 `data` will be bound to the provided token data.
 
-Typically, alias expressions are used in conjunction with one of the `alias_*` filters (e.g. [alias_preserve_format](./filters#alias_preserve_format)
-or [alias_preserve_length](./filters#alias_preserve_length)). These filters randomly generate a secure pseudonym based on the token's data.
+Typically, alias expressions are used in conjunction with one of the `alias_*` filters (e.g. [alias_preserve_format](/docs/expressions/filters#alias_preserve_format)
+or [alias_preserve_length](/docs/expressions/filters#alias_preserve_length)). These filters randomly generate a secure pseudonym based on the token's data.
 For example, if a token contains the credit card number `4242-4242-4242-4242`, the alias expression `{{ data | alias_preserve_format: 0, 4 }}`
 could be used to reveal the last 4 digits in the ID while replacing all the other non-revealed digits with random digits,
 resulting in an ID of the form `9326-7128-4203-4242`.

docs/expressions/detokenization.mdx

@@ -23,11 +23,11 @@ token, then the request will be rejected with a 403 error.
 See the following links for more information about the permissions required to use tokens in a
 [Reactor](/docs/api/reactors#invoke-a-reactor) or [Proxy](/docs/api/proxies/invoke-proxy#proxying-outbound-requests).
 
-Token data can also be transformed before including it in a request by applying [filters](./filters) within an expression.
-In general, filters are applied during detokenization using the syntax:  
+Token data can also be transformed before including it in a request by applying [filters](/docs/expressions/filters) within an expression.
+In general, filters are applied during detokenization using the syntax:
 `{{ <tokenId> | <filter1> | <filter2> | ... }}`
 
-Check out the [detokenization examples](./detokenization#examples) below to see some examples of filters in action.
+Check out the [detokenization examples](/docs/expressions/detokenization#examples) below to see some examples of filters in action.
 
 ## Detokenizing Primitive Data
 

docs/expressions/index.mdx

@@ -19,18 +19,18 @@ Expressions provide a flexible templating language that can be used to apply cus
 
 Expressions can be used within many API endpoints, including:
 
-- [Reactor](/docs/concepts/what-are-reactors) args, to [detokenize](./detokenization) and transform tokens
-- [Proxy](/docs/concepts/what-is-the-proxy) requests, to [detokenize](./detokenization) and transform tokens
-- [Aliasing](#aliasing) when [creating a token](/docs/api/tokens#create-token) or [tokenizing](/docs/api/tokens/tokenize), to specify the id of the created token
-- [fingerprint_expression](./fingerprints) when [creating a token](/docs/api/tokens#create-token) or [tokenizing](/docs/api/tokens/tokenize), to define a value used to generate a token fingerprint
-- [mask](./masks) when [creating a token](/docs/api/tokens#create-token) or [tokenizing](/docs/api/tokens/tokenize), to define the mask applied to the token's data when the actor has restricted permissions
-- [search_indexes](./search-indexes) when [creating a token](/docs/api/tokens#create-token) or [tokenizing](/docs/api/tokens/tokenize), to define indexes to enable [searching tokens](/docs/api/tokens/search)
+- [Reactor](/docs/concepts/what-are-reactors) args, to [detokenize](/docs/expressions/detokenization) and transform tokens
+- [Proxy](/docs/concepts/what-is-the-proxy) requests, to [detokenize](/docs/expressions/detokenization) and transform tokens
+- [Aliasing](/docs/expressions/aliasing) when [creating a token](/docs/api/tokens#create-token) or [tokenizing](/docs/api/tokens/tokenize), to specify the id of the created token
+- [fingerprint_expression](/docs/expressions/fingerprints) when [creating a token](/docs/api/tokens#create-token) or [tokenizing](/docs/api/tokens/tokenize), to define a value used to generate a token fingerprint
+- [mask](/docs/expressions/masks) when [creating a token](/docs/api/tokens#create-token) or [tokenizing](/docs/api/tokens/tokenize), to define the mask applied to the token's data when the actor has restricted permissions
+- [search_indexes](/docs/expressions/search-indexes) when [creating a token](/docs/api/tokens#create-token) or [tokenizing](/docs/api/tokens/tokenize), to define indexes to enable [searching tokens](/docs/api/tokens/search)
 
 ## Language
 
 The expression language used within the Basis Theory API is based on the [Liquid template language](https://shopify.github.io/liquid).
 While all valid Liquid syntax is supported, Basis Theory expressions are typically formed from a combination of
-[objects](#objects) and [filters](./filters).
+[objects](#objects) and [filters](/docs/expressions/filters).
 
 ### Objects
 
@@ -45,4 +45,4 @@ the `data` variable is automatically bound to the token's `data` value. `metadat
 
 When including expressions within Reactor or Proxy requests, token ids may be specified within object expressions,
 and each token id will be bound to the corresponding token's data value.
-See [detokenization](./detokenization) for further details about this process.
+See [detokenization](/docs/expressions/detokenization) for further details about this process.

docs/sdks/mobile/android/events.mdx

@@ -15,9 +15,9 @@ Raised whenever the element's value is changed, upon each keypress and after pas
 
 | Property   | Type                 | Description                                                                                 |
 |------------|----------------------|---------------------------------------------------------------------------------------------|
-| isComplete | `Boolean`            | Whether the element has been completely filled (as specified by the [mask](./options#mask)) |
+| isComplete | `Boolean`            | Whether the element has been completely filled (as specified by the [mask](/docs/sdks/mobile/android/options#mask)) |
 | isEmpty    | `Boolean`            | Whether the element is empty                                                                |
-| isValid    | `Boolean`            | The result of the [validator](./options#validator), or `true` if no validator is specified  |
+| isValid    | `Boolean`            | The result of the [validator](/docs/sdks/mobile/android/options#validator), or `true` if no validator is specified  |
 | details    | `List<EventDetails>` | A list of [EventDetails](#eventdetails) included with this event                            |
 
 ### EventDetails

docs/sdks/mobile/android/index.mdx

@@ -27,16 +27,16 @@ your application code, which keeps your mobile application out of compliance sco
 Here's how we make this possible:
 
 - [Install](#installation) our Android SDK into your mobile application
-- Build forms using our **[Element](./types)** input components
-- [Interact](./services#basistheoryelements) with the Basis Theory API using **Element** references, not plaintext data
-- Own your UI/UX by fully customizing how **Elements** are [styled](./options#styling)
+- Build forms using our **[Element](/docs/sdks/mobile/android/types)** input components
+- [Interact](/docs/sdks/mobile/android/services#basistheoryelements) with the Basis Theory API using **Element** references, not plaintext data
+- Own your UI/UX by fully customizing how **Elements** are [styled](/docs/sdks/mobile/android/options#styling)
 
 ## Collect Sensitive Data
 
 Data entered by your end users into **Elements** is tokenized and secured within Basis Theory's certified Vault.
 
-Our SDKs provide several types of inputs to collect various types of data, such as the [CardNumberElement](./types#cardnumberelement)
-for collecting credit card data and [TextElement](./types#textelement) for collecting arbitrary textual data.
+Our SDKs provide several types of inputs to collect various types of data, such as the [CardNumberElement](/docs/sdks/mobile/android/types#cardnumberelement)
+for collecting credit card data and [TextElement](/docs/sdks/mobile/android/types#textelement) for collecting arbitrary textual data.
 
 Elements can be configured to support custom input masking, validation, and transformation rules to satisfy your use cases.
 
@@ -129,4 +129,4 @@ runBlocking {
 ```
 
 A full example Android app is included within the [example](https://github.com/Basis-Theory/basistheory-android/tree/master/example)
-module within the GitHub repo or explore all the supported [Element Types](./types).
+module within the GitHub repo or explore all the supported [Element Types](/docs/sdks/mobile/android/types).