docs: implement multi-tenancy updates & add versioning

packages/documentation/astro.config.mjs

@@ -7,6 +7,7 @@ import starlightLinksValidator from 'starlight-links-validator'
 import starlightFullViewMode from 'starlight-fullview-mode'
 import { rehypeHeadingIds } from '@astrojs/markdown-remark'
 import rehypeAutolinkHeadings from 'rehype-autolink-headings'
+import starlightVersions from 'starlight-versions'
 
 // https://astro.build/config
 export default defineConfig({
@@ -112,6 +113,10 @@ export default defineConfig({
                   },
                   link: '/overview/concepts/account-servicing-entity'
                 },
+                {
+                  label: 'Multi-tenancy',
+                  link: '/overview/concepts/multi-tenancy'
+                },
                 {
                   label: 'Accounting',
                   translations: {
@@ -184,6 +189,10 @@ export default defineConfig({
                   label: 'Overview and checklist',
                   link: '/integration/requirements/overview'
                 },
+                {
+                  label: 'Tenants',
+                  link: '/integration/requirements/tenants'
+                },
                 {
                   label: 'Assets',
                   link: '/integration/requirements/assets'
@@ -358,12 +367,18 @@ export default defineConfig({
         }
       ],
       plugins: [
+        starlightVersions({
+          current: {
+            label: 'v2-beta'
+          },
+          versions: [{ slug: 'v1-beta' }]
+        }),
         starlightLinksValidator({
           exclude: [
-            '/apis/graphql/auth',
-            '/apis/graphql/backend',
-            '/apis/graphql/auth/*',
-            '/apis/graphql/backend/*'
+            '**/apis/graphql/auth',
+            '**/apis/graphql/backend',
+            '**/apis/graphql/auth/*',
+            '**/apis/graphql/backend/*'
           ],
           errorOnLocalLinks: false,
           errorOnFallbackPages: false,

packages/documentation/package.json

@@ -5,6 +5,7 @@
   "scripts": {
     "start": "astro dev",
     "build:docs": "astro build",
+    "build:docs:graphql": "spectaql config-auth.yml && spectaql config-backend.yml",
     "preview": "astro preview",
     "astro": "astro"
   },
@@ -19,6 +20,7 @@
     "remark-math": "^6.0.0",
     "spectaql": "^3.0.4",
     "starlight-fullview-mode": "^0.2.3",
-    "starlight-links-validator": "^0.17.0"
+    "starlight-links-validator": "^0.17.0",
+    "starlight-versions": "^0.5.5"
   }
 }

packages/documentation/src/components/Header.astro

@@ -1,19 +1,21 @@
 ---
 import { getRelativeLocaleUrl } from 'astro:i18n';
-import Search from "@astrojs/starlight/components/Search.astro";
 import ThemeSelect from "@astrojs/starlight/components/ThemeSelect.astro";
 import LanguageSelect from '@astrojs/starlight/components/LanguageSelect.astro';
 import SocialIcons from "@astrojs/starlight/components/SocialIcons.astro";
 import RafikiLogo from "../components/RafikiLogo.astro";
+import VersionSelect from 'starlight-versions/components/VersionSelect.astro'
+import VersionSearch from 'starlight-versions/components/VersionSearch.astro'
 ---
 <div class="header sl-flex">
   <a href={getRelativeLocaleUrl(Astro.currentLocale ?? 'en', '/')} class="site-logo">
     <RafikiLogo />
   </a>
   <div class="secondary-wrap">
-    <Search />
+    <VersionSearch />
     <SocialIcons />
     <div class="sl-hidden md:sl-flex">
+      <VersionSelect/>
       <ThemeSelect />
     </div>
     <LanguageSelect />

packages/documentation/src/content.config.ts

@@ -1,8 +1,10 @@
 import { defineCollection } from 'astro:content'
 import { docsLoader } from '@astrojs/starlight/loaders'
 import { docsSchema, i18nSchema } from '@astrojs/starlight/schema'
+import { docsVersionsLoader } from 'starlight-versions/loader'
 
 export const collections = {
   docs: defineCollection({ loader: docsLoader(), schema: docsSchema() }),
-  i18n: defineCollection({ type: 'data', schema: i18nSchema() })
+  i18n: defineCollection({ type: 'data', schema: i18nSchema() }),
+  versions: defineCollection({ loader: docsVersionsLoader() })
 }

packages/documentation/src/content/docs/admin/liquidity/asset-liquidity.mdx

@@ -8,15 +8,15 @@ import { Tabs, TabItem } from '@astrojs/starlight/components'
 import { LinkOut } from '@interledger/docs-design-system'
 import IdempotencyNote from '/src/partials/liquidity-idempotency.mdx'
 
-Asset liquidity is the amount of value, denominated in a given asset, that Rafiki has available to handle cross-currency (foreign exchange) transactions between you and your peer. Whenever an outgoing payment/incoming payment is in a different asset than the peering relationship, the liquidity of asset accounts change depending on the FX direction.
+Asset liquidity is the amount of value, denominated in a given asset, that Rafiki has available to handle cross-currency (foreign exchange) transactions between you and your peer. Asset liquidity is managed separately for each tenant. Whenever an outgoing payment/incoming payment is in a different asset than the peering relationship, the liquidity of asset accounts change depending on the FX direction.
 
 You should deposit and withdraw liquidity as necessary, based on your risk tolerance. Rafiki fails any transaction that would cause an asset's liquidity to fall below zero.
 
 For more information about how Rafiki handles liquidity, see the [Accounting](/overview/concepts/accounting) concepts page and the [low asset liquidity](/integration/requirements/webhook-events#low-asset-liquidity) section of the webhook events page.
 
 ## Manage asset liquidity using Rafiki Admin
 
-You can deposit and withdraw asset liquidity through the Rafiki Admin application's [Assets](/admin/admin-user-guide/#edit-asset) screen.
+You can deposit and withdraw asset liquidity through the Rafiki Admin application's [Assets](/admin/admin-user-guide/#edit-asset) screen. Operators can manage asset liquidity for any tenant, while tenants can only manage the liquidity of their own assets.
 
 ## Manage asset liquidity using the Backend Admin API
 

packages/documentation/src/content/docs/admin/liquidity/peer-liquidity.mdx

@@ -7,7 +7,7 @@ tableOfContents:
 import { Tabs, TabItem } from '@astrojs/starlight/components'
 import IdempotencyNote from '/src/partials/liquidity-idempotency.mdx'
 
-Peer liquidity is the line of credit you extend to a peer, denominated in your agreed upon asset. A peer's liquidity account balance represents the amount of credit the peer still has available to them.
+Peer liquidity is the line of credit you extend to a peer, denominated in your agreed upon asset. Peer liquidity is managed separately for each tenant. A peer's liquidity account balance represents the amount of credit the peer still has available to them.
 
 A peer's liquidity increases when payments are made to the peer and decreases when payments are made from the peer. For example, if a customer of your peer sends your customer a payment of $20 USD, then your peer's liquidity account decreases by 20.
 
@@ -17,7 +17,7 @@ For more information about how Rafiki handles liquidity, see the [Accounting](/o
 
 ## Manage peer liquidity using Rafiki Admin
 
-You can deposit and withdraw peer liquidity through the Rafiki Admin application's [Peers](/admin/admin-user-guide/#edit-peer) screen.
+You can deposit and withdraw peer liquidity through the Rafiki Admin application's [Peers](/admin/admin-user-guide/#edit-peer) screen. Operators can manage peer liquidity for any tenant, while tenants cannot manage peer liquidity at all.
 
 ## Manage peer liquidity using the Backend Admin API
 

packages/documentation/src/content/docs/apis/graphql/admin-api-overview.mdx

@@ -8,7 +8,9 @@ Rafiki provides two GraphQL APIs, described below. As described on <LinkOut href
 
 ## Backend Admin API
 
-The Backend Admin API provides you with comprehensive capabilities to manage your Rafiki instance. Core functionality includes managing peering relationships, assets, wallet addresses and their public keys, as well as liquidity management through deposits and withdrawals. Another important aspect of the Backend Admin API is to manage Open Payments resources like payments and quotes.
+The Backend Admin API provides you with comprehensive capabilities to manage your Rafiki instance. Core functionality includes managing tenants, peering relationships, assets, wallet addresses and their public keys, as well as liquidity management through deposits and withdrawals, all within a tenant's context. Another important aspect of the Backend Admin API is to manage Open Payments resources like payments and quotes.
+
+All requests to the Backend Admin API are HMAC-signed using the tenant's API secret and include a `tenant-id` header. See [Backend service](/integration/deployment/services/backend-service#authentication-and-authorization) for more information.
 
 This API is complemented by the Rafiki Admin application, a frontend interface for Rafiki management that directly interacts with the Backend Admin API. Check out the [Rafiki Admin Application User Guide](/admin/admin-user-guide) for more information.
 
@@ -20,8 +22,8 @@ The Auth Admin API allows you to get information about a grant, such as its stat
 
 Wikipedia describes <LinkOut href="https://en.wikipedia.org/wiki/Idempotence">idempotence</LinkOut> as being the property of “certain operations in…computer science whereby [the operations] can be applied multiple times without changing the result beyond the initial application.” “An operation can be repeated or retried as often as necessary without causing unintended effects. With non-idempotent operations, the algorithm may have to keep track of whether the operation was already performed.”
 
-Several mutations in the Admin APIs utilize an idempotency key to allow for safely retrying requests without performing operations multiple times. The key should be unique, typically a V4 UUID.
+Several mutations in the Admin APIs utilize an idempotency key to allow for safely retrying requests without performing operations multiple times. The key must be unique (for example, a UUID v4).
 
-For the Admin APIs, whenever a mutation with an `idempotencyKey` is called, the request payload and the request response are saved under that key. Any subsequent requests made with the same idempotency key will return the original response and status of the request, regardless of whether the request was successful. Keys are cached for a default of 24 hours. The default can be changed via the `backend` service’s `GRAPHQL_IDEMPOTENCY_KEY_TTL_MS backend` environment flag.
+For the Admin APIs, whenever a mutation with an `idempotencyKey` is called, the request payload and the request response are saved under that key. Any subsequent requests made with the same idempotency key will return the original response and status of the request, regardless of whether the request was successful. Keys are cached for a default of 24 hours. The default can be changed via the `backend` service’s `GRAPHQL_IDEMPOTENCY_KEY_TTL_MS` environment flag.
 
-Additionally, in the chance that a request is made while still concurrently processing the first request under the same `idempotencyKey`, the APIs will return an error. This provides further safeguards from potential errors in the system. The timing to prevent processing concurrent requests is `2` seconds by default. The default can be changed via the `backend` service’s `GRAPHQL_IDEMPOTENCY_KEY_LOCK_MS` environment flag.
+If a request is made while the first request under the same `idempotencyKey`, is still processing, the APIs return an error to prevent concurrent duplicates. The concurrency lock duration is `2` seconds by default and can be changed via the `backend` service’s `GRAPHQL_IDEMPOTENCY_KEY_LOCK_MS` environment flag.

packages/documentation/src/content/docs/es/index.mdx

@@ -6,7 +6,7 @@ hero:
   tagline: Rafiki is open source software that provides an efficient solution for an account servicing entity (ASE) to enable Interledger functionality on its users' accounts.
   actions:
     - text: Read Rafiki docs
-      link: /overview/overview
+      link: /es/overview/overview
       icon: open-book
       variant: primary
       attrs:

packages/documentation/src/content/docs/es/v1-beta/index.mdx

@@ -0,0 +1,46 @@
+---
+title: Hello from Rafiki
+description: Rafiki is open source software that provides an efficient solution
+  for an Account Servicing Entity to enable Interledger functionality on its
+  users' accounts.
+template: splash
+hero:
+  tagline:
+    Rafiki is open source software that provides an efficient solution for
+    an account servicing entity (ASE) to enable Interledger functionality on its
+    users' accounts.
+  actions:
+    - text: Read Rafiki docs
+      link: /es/v1-beta/overview/overview
+      icon: open-book
+      variant: primary
+      attrs:
+        data-umami-event: Landing page - Rafiki docs
+slug: es/v1-beta
+---
+
+import { Card, CardGrid, LinkCard } from '@astrojs/starlight/components'
+
+<CardGrid>
+  <a class='card-link' href='/integration/playground/overview'>
+    <Card title='Try it out!' icon='document'>
+      Test Rafiki by running two mock ASEs that automatically peer with one
+      another.
+    </Card>
+  </a>
+  <a class='card-link' href='/integration/requirements/overview'>
+    <Card title='Integration requirements' icon='document'>
+      Review the requirements for deploying Rafiki to a production environment.
+    </Card>
+  </a>
+  <a class='card-link' href='/apis/graphql/backend'>
+    <Card title='View Backend API schema' icon='document'>
+      Discover what's in our Backend GraphQL schema.
+    </Card>
+  </a>
+  <a class='card-link' href='/apis/graphql/auth'>
+    <Card title='View Auth API schema' icon='document'>
+      Discover what's in our Auth GraphQL schema.
+    </Card>
+  </a>
+</CardGrid>

packages/documentation/src/content/docs/es/v1-beta/overview/concepts/account-servicing-entity.mdx

@@ -0,0 +1,38 @@
+---
+title: Servicio de Cuentas de Entidad (ASE)
+slug: es/v1-beta/overview/concepts/account-servicing-entity
+---
+
+An account servicing entity (ASE) is a regulated entity that provides and maintains payment accounts for its customers. Examples of ASEs include banks, digital wallet providers, and mobile money providers.
+
+As regulated entities, ASEs are subject to the laws, rules, and regulations of their jurisdictions. As such, Rafiki should **not** be used in production environments by non-regulated entities.
+
+## Responsibilities and obligations
+
+A few examples of an ASE's responsibilities and obligations include:
+
+- Regulatory compliance
+- Account provisioning and maintenance
+- Transaction handling
+- Ledger management
+- Authentication and consent
+
+### Regulatory compliance
+
+ASEs must onboard account holders in compliance with regulatory requirements, such as performing Know Your Customer (KYC) checks, anti-money laundering (AML) processes, and sanctions screening.
+
+### Account provisioning and maintenance
+
+ASEs manage the creation, upkeep, and security of payment accounts. This includes providing channels for account holders (individuals or businesses) to interact with their accounts via mobile apps, websites, and other interfaces.
+
+### Transaction handling
+
+ASEs handle deposits and withdrawals through various external payment methods such as bank transfers, credit cards, and other payment services.
+
+### Ledger management
+
+ASEs maintain a ledger of account balances and transaction histories for their account holders.
+
+### Authentication and consent
+
+In the context of Open Payments, ASEs are responsible for authenticating resource owners (for example, account holders) and obtaining their consent when clients, such as mobile apps, request access to a resource (for example, an account).