API link updates

Author: Dan Costello

content/docs/guides/(authorization)/Implement-AuthZ-in-3-steps/2-populate-the-graph.mdx

@@ -4,8 +4,8 @@ slug: "2-populate-the-graph"
 excerpt: ""
 hidden: false
 metadata:
-    image: []
-    robots: "index"
+  image: []
+  robots: "index"
 createdAt: "Thu Aug 03 2023 23:20:03 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Fri Aug 04 2023 18:42:07 GMT+0000 (Coordinated Universal Time)"
 ---
@@ -15,12 +15,12 @@ import { Step, Steps } from "fumadocs-ui/components/steps";
 Once you have designed the structure of your model, it's time to build your database of <Glossary>object</Glossary>s and <Glossary>edge</Glossary>s in UserClouds. This can be done in two steps:
 
 <Steps>
-    <Step>Migrate over from a pre-existing identity system &nbsp;</Step>
-    <Step>
-        Implement UserClouds's APIs to [populate the graph with
-        objects](/docs/reference/post_authz-objects) and
-        [edges](/docs/reference/post_authz-edges) on an ongoing basis &nbsp;
-    </Step>
+  <Step>Migrate over from a pre-existing identity system &nbsp;</Step>
+  <Step>
+    Implement UserClouds's APIs to [populate the graph with
+    objects](/docs/reference/authz/objects/post) and
+    [edges](/docs/reference/authz/edges/post) on an ongoing basis &nbsp;
+  </Step>
 </Steps>
 
 If you are building your product or user base from scratch, you will skip straight to step 2.
@@ -31,6 +31,6 @@ UserClouds supports mass migration from pre-existing AuthN and AuthZ systems, li
 
 ## 2. Implement Write APIs in your software
 
-Maintaining your authorization graph is simple with UserClouds's CRUD APIs. These allow you to [create Objects](/docs/reference/post_authz-objects) and [Edges](/docs/reference/post_authz-edges) programmatically in your application.
+Maintaining your authorization graph is simple with UserClouds's CRUD APIs. These allow you to [create Objects](/docs/reference/authz/objects/post) and [Edges](/docs/reference/authz/edges/post) programmatically in your application.
 
-For more information on the APIs for Authorization, check out our [Authorization API Docs](/docs/reference/post_authz-objects).
+For more information on the APIs for Authorization, check out our [Authorization API Docs](/docs/reference/authz/objects/post).

content/docs/guides/(authorization)/Implement-AuthZ-in-3-steps/3-run-permissions-checks.mdx

@@ -6,10 +6,11 @@ hidden: false
 createdAt: "Thu Aug 03 2023 23:22:50 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Thu Jun 06 2024 17:25:04 GMT+0000 (Coordinated Universal Time)"
 ---
-Once you have populated UserClouds with your types, objects and edges, UserClouds is ready to be the source-of-truth for permissions. To implement <Glossary>permission</Glossary>s in your system, all you need to do is add UserClouds's [Permission Check APIs](/docs/reference/get_authz-checkattribute) in the appropriate places in your software.
+
+Once you have populated UserClouds with your types, objects and edges, UserClouds is ready to be the source-of-truth for permissions. To implement <Glossary>permission</Glossary>s in your system, all you need to do is add UserClouds's [Permission Check APIs](/docs/reference/authz/checkattribute) in the appropriate places in your software.
 
 - **CheckAttribute** answers the question: does user X have permission Y on object Z?
 - **ListAttributes** receives a source object ID and target object ID. It returns a list of attributes that the source object has on the target object.
 - **ListObjectsReachableWithAttribute** receives an attribute and a source object ID. It returns a list of objects reachable with that attribute.
 
-For more information, check out our [Authorization API Docs](/docs/reference/get_authz-checkattribute).
+For more information, check out our [Authorization API Docs](/docs/reference/authz/checkattribute).

content/docs/guides/(data-access)/definitions/access-policies.mdx

@@ -6,6 +6,7 @@ hidden: false
 createdAt: "Thu Aug 03 2023 19:17:40 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Tue Sep 10 2024 18:36:12 GMT+0000 (Coordinated Universal Time)"
 ---
+
 Access Policies control the circumstances under which data can be retrieved or edited. These policies are functions that receive contextual data and return true or false to determine whether access is allowed or denied. The context is generated from the server and can be combined with additional context sent from the client.
 
 Access Policies are executed in three places in UserClouds:
@@ -43,7 +44,7 @@ Access policies evaluate claims and key/value pairs in the provided context. The
   - **context.server.purpose_names**: the purposes specified on an accessor to which this access policy is attached (does not apply in all cases)
   - **context.server.ip_address**: the IP address of the user or system initiating the request
 - **context.client**: This context contains key/value pairs specified in the request comments by the client and is not considered trusted. It includes data such as user-specified parameters that are not verified by the server.
-- **context.user**: Information about data for the user whose data is row being accessed.  
+- **context.user**: Information about data for the user whose data is row being accessed.
   evaluated by the access policy
 - **context.query**: Specific query parameters relevant to the request.
 - **context.row_data**: Specific Column data for the user row data values related to being evaluated by the request.
@@ -57,19 +58,19 @@ Access Policies are composed from Access Policy Templates. Templates are paramet
 ### Template function
 
 ```javascript
-function getAge(DOB) {  
-    const today = new Date();  
-    const birthDate = new Date(DOB);  
-    let age = today.getFullYear() - birthDate.getFullYear();  
-    const m = today.getMonth() - birthDate.getMonth();  
-    if (m \< 0 || (m === 0 && today.getDate() \< birthDate.getDate())) {  
-        age--;  
-    }  
-    return age;  
+function getAge(DOB) {
+    const today = new Date();
+    const birthDate = new Date(DOB);
+    let age = today.getFullYear() - birthDate.getFullYear();
+    const m = today.getMonth() - birthDate.getMonth();
+    if (m \< 0 || (m === 0 && today.getDate() \< birthDate.getDate())) {
+        age--;
+    }
+    return age;
 }
 
-function policy(context, params) {  
-  return getAge(context.user[params.column_name]) >= params.expected_years_old;  
+function policy(context, params) {
+  return getAge(context.user[params.column_name]) >= params.expected_years_old;
 }
 ```
 
@@ -87,10 +88,10 @@ Here is an example of how you can create a policy to check if the country claim
 ### Template function
 
 ```javascript
-function policy(context, params) {  
-    const country = context.server.claims.country;  
-    const specifiedCountry = params.specified_country;  
-    return country === specifiedCountry;  
+function policy(context, params) {
+  const country = context.server.claims.country;
+  const specifiedCountry = params.specified_country;
+  return country === specifiedCountry;
 }
 ```
 
@@ -108,10 +109,10 @@ If the country information is not in the JWT but in the client context, the poli
 ### Template function
 
 ```javascript
-function policy(context, params) {  
-    const country = context.client.country;  
-    const specifiedCountry = params.specified_country;  
-    return country === specifiedCountry;  
+function policy(context, params) {
+  const country = context.client.country;
+  const specifiedCountry = params.specified_country;
+  return country === specifiedCountry;
 }
 ```
 
@@ -139,13 +140,16 @@ The built-in `networkRequest` function allows you to reach external services via
 This example shows how to make a network request to verify the user's country based on their IP address. Note that the interface for `networkRequest` is synchronous, as in the example below:
 
 ```javascript
-function policy(context, params) {  
-  let countryCode = null;  
-  const resp = networkRequest({url: `https://api.iplocation.net/?ip=${context.server.ip_address}`, method: 'GET' });  
-  if (resp) {  
-    countryCode = JSON.parse(resp).country_code2;  
-  }  
-  return countryCode === "US";  
+function policy(context, params) {
+  let countryCode = null;
+  const resp = networkRequest({
+    url: `https://api.iplocation.net/?ip=${context.server.ip_address}`,
+    method: "GET",
+  });
+  if (resp) {
+    countryCode = JSON.parse(resp).country_code2;
+  }
+  return countryCode === "US";
 }
 ```
 
@@ -156,51 +160,51 @@ This example shows how to verify an employee is active in a private employee dir
 #### Template Function
 
 ```javascript
-function policy(context, params) {  
+function policy(context, params) {
   let isActiveEmployee = false;
 
-  const resp = networkRequest({  
-    url: `https://api.company.com/employees/${context.user.id}/status`,  
-    method: 'GET',  
-    headers: {  
-      'Authorization': 'Basic ' + btoa('username:password'),  
-      'Content-Type': 'application/json'  
-    }  
+  const resp = networkRequest({
+    url: `https://api.company.com/employees/${context.user.id}/status`,
+    method: "GET",
+    headers: {
+      Authorization: "Basic " + btoa("username:password"),
+      "Content-Type": "application/json",
+    },
   });
 
-  if (resp) {  
-    const employeeData = JSON.parse(resp);  
-    isActiveEmployee = employeeData.status === "active";  
+  if (resp) {
+    const employeeData = JSON.parse(resp);
+    isActiveEmployee = employeeData.status === "active";
   }
 
-  return isActiveEmployee;  
+  return isActiveEmployee;
 }
 ```
 
 #### Parameters to instantiate a policy
 
 ```javascript
 // Example Policy Parameters (not specified in the template function)
-const params = {};  // No specific parameters needed for this example
+const params = {}; // No specific parameters needed for this example
 ```
 
 ## checkAttribute
 
-The `checkAttribute` function runs a permission check against the UserClouds authorization graph. If you are using UserClouds for authorization as a service, this can verify if a user has the necessary permissions. In short, it asks whether a given object (usually a user) has an attribute (e.g. "can-read" or "is-admin") on another object (which could be just about any entity in your system). You can read more about this in the [Authorization Documentation](/docs/reference/get_authz-checkattribute).
+The `checkAttribute` function runs a permission check against the UserClouds authorization graph. If you are using UserClouds for authorization as a service, this can verify if a user has the necessary permissions. In short, it asks whether a given object (usually a user) has an attribute (e.g. "can-read" or "is-admin") on another object (which could be just about any entity in your system). You can read more about this in the [Authorization Documentation](/docs/reference/authz/checkattribute).
 
 ### Example
 
 **Use Case: Does the calling user have view permission on the target user?**
 
 ```javascript
 function policy(context) {
-    const callingUserId = context.user.id;
-    const targetUserId = context.params.targetUserId;
-    const attribute = "viewPermission";
-    if (!callingUserId || !targetUserId || !attribute) {
-        return false;
-    }
-    return checkAttribute(callingUserId, targetUserId, attribute);
+  const callingUserId = context.user.id;
+  const targetUserId = context.params.targetUserId;
+  const attribute = "viewPermission";
+  if (!callingUserId || !targetUserId || !attribute) {
+    return false;
+  }
+  return checkAttribute(callingUserId, targetUserId, attribute);
 }
 ```
 
@@ -216,19 +220,19 @@ function policy(context) {
 ### Example
 
 ```javascript
-function policy(context, params) {  
+function policy(context, params) {
   let { phone_numer } = params; // e.g. "+12065551234"
-  const country = getCountryNameForPhoneNumber(phone_number);  
-   
-  return country.alpha_2 === "US";  
+  const country = getCountryNameForPhoneNumber(phone_number);
+
+  return country.alpha_2 === "US";
 }
 ```
 
 # Managing access policies
 
 UserClouds has several built-in access policies for common use cases, like role-based and time-based expiration of data. However you can also create custom policies, in two ways:
 
-- Call the [CreateAccessPolicy API](/docs/reference/post_tokenizer-policies-access)
+- Call the [CreateAccessPolicy API](/docs/reference/tokenizer/policies/access/post)
 - Compose a new policy from existing policies and parametrizable templates in the UserClouds Console
 
 To learn more about creating access policies, see our How to Guide on Creating Access Policies.

content/docs/guides/(data-access)/definitions/accessors-read-apis.mdx

@@ -6,6 +6,7 @@ hidden: false
 createdAt: "Thu Aug 03 2023 19:30:50 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Tue Sep 10 2024 16:09:30 GMT+0000 (Coordinated Universal Time)"
 ---
+
 Accessors are configurable APIs that allow a client to retrieve data from the user store. Accessors are intended to be use-case specific. For example, you might configure two separate accessors `GetEmailForMarketing` and `GetEmailForAuthentication`. They enforce data usage policies and minimize outbound data from the store for their given use case.
 
 As an example of data minimization, you might configure an accessor called `GetPhoneCountryCodeForAnalytics` that returns the country code of a user's phone number when called, instead of the raw phone number. This reduces the sensitivity of the data outside your store, minimizing your surface area for an attack and simplifying compliance.
@@ -25,7 +26,7 @@ Accessors can be configured to access either live or soft-deleted data. Soft-del
    2. **Column-default access policies**: Column default policies for all columns accessed by the accessor are applied, unless overridden. Learn more [here](/docs/protect-a-column-with-defaults).
    3. **Accessor-specific access policy composition**: Applied in addition to the above policies.
 4. User data is further filtered according to whether the users have consented to the accessor's data processing purpose.
-5. For records where access is granted, the accessor's <Glossary>data transformer</Glossary>s transform each column of the outbound data, minimizing the data for the given use case. If no transformer is specified for a given column, the column's default transformer is used. Learn more [here](/docs/protect-a-column-with-defaults). 
+5. For records where access is granted, the accessor's <Glossary>data transformer</Glossary>s transform each column of the outbound data, minimizing the data for the given use case. If no transformer is specified for a given column, the column's default transformer is used. Learn more [here](/docs/protect-a-column-with-defaults).
 
 ## Structure of an Accessor
 
@@ -42,4 +43,4 @@ At creation time, each accessor is associated with a user record <Glossary>selec
 For more info on accessors, see:
 
 - [Creating an accessor](/docs/create-an-accessor)
-- [Executing an accessor](/docs/reference/post_userstore-api-accessors)
+- [Executing an accessor](/docs/reference/userstore/api/accessors)

content/docs/guides/(data-access)/definitions/transformers.mdx

@@ -6,12 +6,12 @@ hidden: false
 createdAt: "Thu Aug 03 2023 19:18:00 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Tue Sep 10 2024 18:37:33 GMT+0000 (Coordinated Universal Time)"
 ---
+
 Transformers are re-usable functions that manipulate data in UserClouds. They allow you to minimize the data that you pass or store for each use case. This is key for complying with the data minimization principles in regulations like GDPR.
 
 ![Transformers can be arbitrarily smart about how they obfuscate data.](/assets/images/user-data.webp)
 
-
-Transformers allow you to retain select structure and information from the raw data for different use cases, like sorting alphabetically, zip code analysis or simply flowing through your systems without triggering validation errors.  For example, if you want to conduct analysis assessing the differences in behavior between children and adults, you may use a data transformer to pass a string indicating `child` or `adult`, instead of pulling raw Date of Birth from the store.
+Transformers allow you to retain select structure and information from the raw data for different use cases, like sorting alphabetically, zip code analysis or simply flowing through your systems without triggering validation errors. For example, if you want to conduct analysis assessing the differences in behavior between children and adults, you may use a data transformer to pass a string indicating `child` or `adult`, instead of pulling raw Date of Birth from the store.
 
 Transformers are executed in two places:
 
@@ -24,7 +24,7 @@ In addition, column default transformers provide a way to consistently apply tra
 
 ## Examples of Transformers
 
-Transformers range from the simplest UUID function that replaces any given data with a unique identifier, to custom-written Javascript that runs in a carefully-controlled sandbox. 
+Transformers range from the simplest UUID function that replaces any given data with a unique identifier, to custom-written Javascript that runs in a carefully-controlled sandbox.
 
 ![One simple transformer receives raw data, and creates a UUID token.](/assets/images/uuid-input.webp)
 
@@ -65,7 +65,7 @@ A transformer consists of:
 
 UserClouds has several off-the-shelf transformers for common use cases, like masking emails, national ID numbers and credit card details. However you can also create custom functions, in three ways:
 
-1. Call the [CreateTransformer API](/docs/reference/post_tokenizer-policies-transformation)
+1. Call the [CreateTransformer API](/docs/reference/tokenizer/policies/transformation/post)
 2. Create functions in the UserClouds UI
 
 For more info on creating transformers, see our How To Guide on Creating a Transformer.

content/docs/guides/(data-access)/how-to-guides/apply-global-protection-policies.mdx

@@ -6,6 +6,7 @@ hidden: false
 createdAt: "Tue Jul 30 2024 16:39:16 GMT+0000 (Coordinated Universal Time)"
 updatedAt: "Tue Jul 30 2024 16:40:29 GMT+0000 (Coordinated Universal Time)"
 ---
+
 This guide explains how to update and use global baseline policies.
 
 Global baseline policies are access policies that get applied by default to all accessors (or mutators). These policies ensure a consistent security baseline across all data operations. Global baseline policies cannot be overridden for individual accessors or mutators.
@@ -21,7 +22,7 @@ Global baseline policies are access policies that get applied by default to all
 
 ## Setting Global Baseline Policies
 
-Global baseline policies are provisioned during tenant creation. They can be found and edited on the access policies page. These policies can be composed of other policies and templates. Additionally, they can be edited via the Update Access Policy API. For more details on editing global baseline policies, see the [API reference](/docs/reference/put_tokenizer-policies-access-id).
+Global baseline policies are provisioned during tenant creation. They can be found and edited on the access policies page. These policies can be composed of other policies and templates. Additionally, they can be edited via the Update Access Policy API. For more details on editing global baseline policies, see the [API reference](/docs/reference/tokenizer/policies/access/get).
 
 ## Combining Policies