(feat): ai access page

src/data/navigation.js

@@ -23,6 +23,7 @@ const navigation = [
       { title: "Notifications", href: "/docs/features/notifications" },
       { title: "Space Invitations", href: "/docs/features/space_invitations" },
       { title: "Skill Sync", href: "/docs/features/skill_sync" },
+      { title: "AI Access", href: "/docs/features/ai_access" },
     ],
   },
   {

src/pages/docs/features/ai_access.md

@@ -0,0 +1,28 @@
+---
+title: AI Access
+---
+
+With the new **AI Access** feature in the Cirro Developer Interface, you can easily request and manage API tokens for AI integrations. These tokens allow you to enhance your applications with AI capabilities like OpenAI. This feature is accessible through the Cirro UI and is designed to help developers streamline their API access needs.
+
+---
+
+## AI Access Requests
+
+The **AI Access** feature provides a simple way to request API tokens for AI services. Each request corresponds to a set number of tokens, and once provisioned, these tokens will be displayed in your Cirro Developer Interface.
+
+## Requesting API Tokens:
+
+- To request tokens, go to the **Configure** tab and navigate to the **AI Access** section.
+- Enter the number of tokens you need in the **Token Quantity** field (maximum 2 tokens).
+- Once you’ve entered a valid number, click the **Request AI tokens** button. This action triggers a request workflow.
+- You will be able to see your provisioned tokens in the same interface once they have been added to the database.
+
+## Managing API Tokens
+
+Once your token has been provisioned, the **AI Access** section in the Cirro Developer Interface will display it with a unique ID. You can then manage your tokens directly from the interface.
+
+## Token Management Options:
+
+- **Copy Token**: Next to each token, there is a **copy icon** that allows you to quickly copy the token to your clipboard for easy integration into your application.
+- **Re-generate Token**: You can regenerate the token if needed. This will deactivate the old token and generate a new one.
+- **Revoke Token**: If a token is no longer needed, you can revoke it to ensure it is not misused.

src/pages/docs/features/gigs_invitations.md

@@ -2,14 +2,16 @@
 title: Gigs & Invitations
 description: Creating Gigs and inviting Workers.
 ---
-In the [Terminology](https://guides.cirro.io/docs/terminology) section we have already discussed **Gigs**; *a gig is an opportunity for a user to perform a task (and earn a reward). Your space can create gigs which trigger Cirro to start looking for matching users and invite them through an invitation notification.* You could read further about invitations under [Notifications](https://guides.cirro.io/docs/features/notifications).
+
+In the [Terminology](https://guides.cirro.io/docs/terminology) section we have already discussed **Gigs**; _a gig is an opportunity for a user to perform a task (and earn a reward). Your space can create gigs which trigger Cirro to start looking for matching users and invite them through an invitation notification._ You could read further about invitations under [Notifications](https://guides.cirro.io/docs/features/notifications).
 
 Before you could invite users to your space, it must tell Cirro about the gig that you want to invite the users to. Each gig goes through the created -> start -> end -> archived cycle. You invite users to join the gig between the start -> end phases. You are not allowed to update the attributes 'title', 'description', 'url' and 'start_at' if 'start_at' is in the past, and you can only delete a gig with 'start_at' in the future.
 
 Every space needs to provide a clear flow on how to:
-* allow workers to view their invitations
-* accept or reject an invitation
-* view their gigs
+
+- allow workers to view their invitations
+- accept or reject an invitation
+- view their gigs
 
 Your space keeps this data in sync with Cirro in the background, letting the API know when a user has accepted or rejected an invitation.
 As all of the spaces must keep Cirro up-to-date with whether or not a user has accepted an invitation, Cirro also provides an overview of all gigs across all spaces the user is active in.

src/pages/docs/features/notifications.md

@@ -2,20 +2,25 @@
 title: Notifications
 description: What are Cirro notifications?
 ---
+
 With the help of the built-in Cirro notification system, you can communicate with users offline about the important topics of your space. Based on our [example space](https://guides.cirro.io/docs/example_space), you invite volunteers via notifications to participate in a tree-planting event or inform them about the number of trees planted during the most recent event they participated in. The Cirro notification system is ready to be used via API and can be easily configured and maintained though Cirro's UI. We recommend using it as it protects users personal information and makes it easier to focus on building and growing your space. Cirro does not provide a frontend interface for your users, thus online / live communication is not supported by Cirro Notifications, you have to build and operate your own application for this purpose. On this page you encounter some Cirro-related terms that you can look up [here](https://guides.cirro.io/docs/terminology).
-	
+
 ## Cirro notifications
-Communication with users is managed via **Notifications**. A notification represents a message sent to a user in a certain way at a particular point in time. Based on the needs of your space, you can configure a variety of delivery mechanisms. A common type of notification is the **"gig invitation"** notification, that is delivered each time when users match the criteria of a gig and have been invited to join. Using our example, the users are invited in an email to participate in the upcoming tree-planting event. 
+
+Communication with users is managed via **Notifications**. A notification represents a message sent to a user in a certain way at a particular point in time. Based on the needs of your space, you can configure a variety of delivery mechanisms. A common type of notification is the **"gig invitation"** notification, that is delivered each time when users match the criteria of a gig and have been invited to join. Using our example, the users are invited in an email to participate in the upcoming tree-planting event.
 
 ### Notification Topic
+
 Once a user is fully onboarded in your space, they can start receiving notifications of various kinds. Notifications are differentiated based on their **Notification Topic**. Every space has a **"new gig invitation"** notification topic created by default. You can set up additional space-specific notification topics, for example "onboarding completed" notification topic to notify users that they have completed the onboarding process of your space or "gig result accepted" notification topic to let users know that their work in the gig had been accepted and would be paid out.
 
 ### Notification Template
+
 Each notification topic has a **Notification Template**, that defines the topic's delivery mechanism (email), format (text / html), kind (standalone / digest) and locale (en, de etc.). Currently you can set up four templates:
-  * email-text-standalone
-  * email-text-digest
-  * email-html-standalone
-  * email-html-digest
+
+- email-text-standalone
+- email-text-digest
+- email-html-standalone
+- email-html-digest
 
 You can use dynamic variables with liquid syntax, here is an example for an html email template:
 
@@ -31,19 +36,20 @@ HTML
 ```
 
 ### Notification Broadcast
+
 If you wish to send a particular message to a certain or group of users, you need to create a **Notification Broadcast**. When you broadcast a message for a notification topic, Cirro is triggered to create individual notifications for each recipient defined in the broadcast, so each user receives your message.
 
 ### Notification Layouts
-You can choose between two types of **Notification Layouts** to style your notification: Cirro (default) and Custom. If you use the Cirro (default) Layout, your message has a header with a logo, a body with the message and a footer with additional information. 
+
+You can choose between two types of **Notification Layouts** to style your notification: Cirro (default) and Custom. If you use the Cirro (default) Layout, your message has a header with a logo, a body with the message and a footer with additional information.
 
 However, we recognize that Spaces are likely to reach a point where they do want control over every detail of their communication with users. In this case, you can create your own custom notification layout and attach your notification topics to it. This way you provide full layout plus content templates for your topics.
 
 In case of an email notification, this means you will be responsible for the `<html>`, `<head>`, and `<body>` tags and everything there within.
 
 #### Mandatory Placeholders
+
 The one key caveat when you use custom layout is that you must now be sure to provide a placeholder in your email templates for the notice that Cirro legally must include in all emails to workers.
-
 This notice will provide an unsubscribe link as well as additional information about the Cirro platform.
 You will be unable to create or update templates for a topic that uses custom layout unless that templates include the `%{cirro_notice}` placeholder somewhere.
 When crafting your own custom email templates, we recommend that you place this notice placeholder in a properly integrated "footer" section of the email.
-

src/pages/docs/features/results_rewards.md

@@ -2,6 +2,7 @@
 title: Results & Rewards
 description: Submitting results and rewarding Workers.
 ---
-Once the users of your space have finished working on a task, thus completed a gig, they submit the results and get rewarded accordingly. Using our example space to demonstrate the case in practice - once your user (worker) has planted trees (gig results) in a tree planting event (gig) for a certain amount of time (gig time activitiy), they submit their work to be reviewed. 
+
+Once the users of your space have finished working on a task, thus completed a gig, they submit the results and get rewarded accordingly. Using our example space to demonstrate the case in practice - once your user (worker) has planted trees (gig results) in a tree planting event (gig) for a certain amount of time (gig time activitiy), they submit their work to be reviewed.
 
 The work done by the user does not get rewarded automatically, it has to go through a review process by an approver. The approvers can either approve or reject the work. If the work is approved, there are two types of payment forms a user can be compensated with; time based and money based. So a tree planting worker can be rewarded for planted trees by being allocated time or being paid. Your space logs then submits payment-related information (gig results) and time spent on the activity (gig time activities) to Cirro, that rewards your user accordingly. Your users are not compensated for their work rejected by the approver.

src/pages/docs/features/space_invitations.md

@@ -2,6 +2,7 @@
 title: Space Invitations
 description: Inviting users to your Space via Cirro.
 ---
-You can use **Space Invitations** to invite users to join your space. Using our example space, you send an invitation email to volunteers to join your tree-planting site. Cirro allows you to create an invitation for which it sends out an invitation email. The invited user is then redirected to a URL included in the invite. Make sure not to leave the URL blank, otherwise the user you wish to invite gets redirected to your public URL, without being invited to your space. 
+
+You can use **Space Invitations** to invite users to join your space. Using our example space, you send an invitation email to volunteers to join your tree-planting site. Cirro allows you to create an invitation for which it sends out an invitation email. The invited user is then redirected to a URL included in the invite. Make sure not to leave the URL blank, otherwise the user you wish to invite gets redirected to your public URL, without being invited to your space.
 
 Apart from creating a space invitation, you can expire it also.

src/pages/docs/webhooks.md

@@ -2,15 +2,19 @@
 title: Webhooks
 description: Getting important updates from Cirro.
 ---
-Webhooks are means of communication between apps; they provide a way in which apps convey information between each other. Each space can have one or multiple webhooks / configurations, each configuration containing the space's webhook url and a secret. Cirro uses webhooks to communicate with its space, currently it can inform its spaces about two events: 
-* user.updated (happens when user information, such as first name, last name or skills for an Epamer are changed)
-* invitation.created (happens when a user is invited to a gig for the first time)
+
+Webhooks are means of communication between apps; they provide a way in which apps convey information between each other. Each space can have one or multiple webhooks / configurations, each configuration containing the space's webhook url and a secret. Cirro uses webhooks to communicate with its space, currently it can inform its spaces about two events:
+
+- user.updated (happens when user information, such as first name, last name or skills for an Epamer are changed)
+- invitation.created (happens when a user is invited to a gig for the first time)
 
 In order to utilise webhooks
-* you need to make sure event types are available
-* configuration as well as subscriptions have been created
-* you need to use the secret to authenticate your webhook urls
 
-A space can either 
-* subscribe to multiple different events using the same configuration (there is one single endpoint maintained, that receives and handles all webhook events from Cirro)
-* use different configurations to subscribe to each event (there are multiple endpoints maintained, each receiving and handling a specific webhook event from Cirro)
+- you need to make sure event types are available
+- configuration as well as subscriptions have been created
+- you need to use the secret to authenticate your webhook urls
+
+A space can either
+
+- subscribe to multiple different events using the same configuration (there is one single endpoint maintained, that receives and handles all webhook events from Cirro)
+- use different configurations to subscribe to each event (there are multiple endpoints maintained, each receiving and handling a specific webhook event from Cirro)