diff --git a/.claude/skills/connector-docs.md b/.claude/skills/connector-docs.md index e9e84f6e..561fa597 100644 --- a/.claude/skills/connector-docs.md +++ b/.claude/skills/connector-docs.md @@ -1,13 +1,13 @@ --- name: c1-connector-docs -description: Write connector documentation for C1 following the established template structure. Use when creating new connector docs in /baton/, updating existing connector pages, or reviewing connector documentation. Ensures consistency with the standardized connector doc format including capabilities tables, credential gathering, and cloud/self-hosted configuration tabs. +description: Write connector documentation for C1.ai following the established template structure. Use when creating new connector docs in /baton/, updating existing connector pages, or reviewing connector documentation. Ensures consistency with the standardized connector doc format including capabilities tables, credential gathering, and cloud/self-hosted configuration tabs. --- -# C1 Connector Documentation +# C1.ai Connector Documentation > **Heads up:** A copy of this skill also lives in [`ConductorOne/baton-admin`](https://github.com/ConductorOne/baton-admin/blob/main/pkg/files/.claude/skills/connector/build-connector-docs.md). If you update this file, copy the changes there too. -Write connector documentation for the `/baton/` directory following C1's standardized template. +Write connector documentation for the `/baton/` directory following C1.ai's standardized template. ## When to Use This Skill @@ -19,7 +19,7 @@ Use this skill when: ## File Format -**Location:** Connector docs live in the connector's GitHub repository in the [C1 organization](https://github.com/ConductorOne), not in this docs repo. Search for the connector repo by name (e.g., `baton-okta`, `baton-salesforce`) to find the right repo. +**Location:** Connector docs live in the connector's GitHub repository in the [C1.ai organization](https://github.com/ConductorOne), not in this docs repo. Search for the connector repo by name (e.g., `baton-okta`, `baton-salesforce`) to find the right repo. **Naming:** The doc file should be named `docs.mdx` and placed in the root or a `docs/` directory of the connector repo, following the convention already established in that repo. @@ -156,7 +156,7 @@ The [App Name] connector supports [automatic account provisioning](/product/admi ### Connector Actions Section (if applicable) -Some connectors support custom actions that can be used in C1 automations. Add this section after the Capabilities table if the connector supports actions. +Some connectors support custom actions that can be used in C1.ai automations. Add this section after the Capabilities table if the connector supports actions. ```mdx ### Connector actions @@ -359,15 +359,15 @@ For more information, see [link to vendor docs]. name: baton-[connector-name]-secrets type: Opaque stringData: - # C1 credentials - BATON_CLIENT_ID: - BATON_CLIENT_SECRET: + # C1.ai credentials + BATON_CLIENT_ID: + BATON_CLIENT_SECRET: # [App Name] credentials BATON_[APP]_[CREDENTIAL_1]: BATON_[APP]_[CREDENTIAL_2]: - # Optional: include if you want C1 to provision access using this connector + # Optional: include if you want C1.ai to provision access using this connector BATON_PROVISIONING: true ``` diff --git a/.claude/skills/docs-writing.md b/.claude/skills/docs-writing.md index 2a830fa5..ae2d074f 100644 --- a/.claude/skills/docs-writing.md +++ b/.claude/skills/docs-writing.md @@ -1,16 +1,16 @@ --- name: c1-docs-writer -description: Write documentation for C1's website following established voice, tone, and style guidelines. Use when creating new documentation pages, updating existing docs, writing how-to guides, or any content for conductorone.com/docs. Ensures consistency with C1's direct, action-oriented documentation style. +description: Write documentation for C1.ai's website following established voice, tone, and style guidelines. Use when creating new documentation pages, updating existing docs, writing how-to guides, or any content for conductorone.com/docs. Ensures consistency with C1.ai's direct, action-oriented documentation style. --- -# C1 Documentation Writer +# C1.ai Documentation Writer -Write C1 documentation that matches the established voice, tone, and style of the existing docs site. +Write C1.ai documentation that matches the established voice, tone, and style of the existing docs site. ## When to Use This Skill Use this skill when: -- Creating new documentation pages for C1 +- Creating new documentation pages for C1.ai - Writing or updating how-to guides - Drafting admin guides or end-user documentation - Creating quickstart guides @@ -18,11 +18,11 @@ Use this skill when: ## The docs voice -Documentation has a different job than marketing. Marketing makes a case for C1. Docs assume the reader already chose C1 — they're here to get something done. The voice shifts accordingly: less energetic, more instructive. +Documentation has a different job than marketing. Marketing makes a case for C1.ai. Docs assume the reader already chose C1.ai — they're here to get something done. The voice shifts accordingly: less energetic, more instructive. **Outside-in framing.** Lead with what the reader is trying to accomplish, not with the feature name or how it works internally. "If you run recurring campaigns, use a template to avoid reconfiguring from scratch each time" is outside-in. "Campaign templates are a feature that allows..." is not. The opening sentence of every page should tell the reader what they can *do* after reading it — not what the feature *is*. -**Declarative, not hedged.** If something is true, say it plainly. Don't write "C1 can help streamline the approval process." Write "C1 auto-approves requests that meet policy." Hedging makes docs feel uncertain; readers lose confidence in the product. +**Declarative, not hedged.** If something is true, say it plainly. Don't write "C1.ai can help streamline the approval process." Write "C1.ai auto-approves requests that meet policy." Hedging makes docs feel uncertain; readers lose confidence in the product. **Peer-level respect.** The reader is a security or IT professional. They know why access reviews matter. They need to know how to run one. Skip context they already have and get to the task. @@ -31,7 +31,7 @@ Documentation has a different job than marketing. Marketing makes a case for C1. - Do: "New tasks will now be automatically reassigned to your delegate." - Don't: "That's it! Tasks will now be assigned to your delegate." -**Active voice, specific verbs.** "C1 sends a notification" not "a notification is sent." "Click **Save**" not "the Save button should be clicked." +**Active voice, specific verbs.** "C1.ai sends a notification" not "a notification is sent." "Click **Save**" not "the Save button should be clicked." **Avoid hedging verbs.** These drain sentences of authority: - "helps you to" → use a direct verb @@ -45,7 +45,7 @@ Documentation has a different job than marketing. Marketing makes a case for C1. ## File Format -**Always use .mdx format** for C1 documentation files. MDX (Markdown with JSX) is the required format for the docs site. When creating new documentation, save files with the `.mdx` extension. +**Always use .mdx format** for C1.ai documentation files. MDX (Markdown with JSX) is the required format for the docs site. When creating new documentation, save files with the `.mdx` extension. ### Content Structure @@ -56,7 +56,7 @@ Documentation has a different job than marketing. Marketing makes a case for C1. ## File and Folder Structure -C1 docs use Mintlify, where **file path = URL**. Structure decisions are permanent without redirects, so be intentional. +C1.ai docs use Mintlify, where **file path = URL**. Structure decisions are permanent without redirects, so be intentional. ### Folder rules @@ -95,7 +95,7 @@ Sidebar grouping in `docs.json` is independent of folder structure. You can visu - Are there any hedging verbs, editorializing phrases, or throat-clearing openers? - Does any sentence try to serve too many stakeholders at once? Split it or cut it. - After each procedure, is there an outcome sentence stating what changed? - - Is the company name "C1" throughout? + - Is the company name "C1.ai" throughout? ## Key Style Points @@ -211,14 +211,14 @@ When documenting features that are in early access, add a standardized warning c **Key points:** - Always use `` (not `` or ``) -- Always use "the C1 Support team" (not "our Support team" or "your account team") +- Always use "the C1.ai Support team" (not "our Support team" or "your account team") - Don't name the specific feature (use "This feature") - Include the explanation of what early access means - Use "share feedback" (not "have any feedback") ## Hosting region references (default instance vs. EU data residency) -C1 runs two hosting options — a **default instance** (`conductor.one`) and an **EU data residency instance** (`c1eu.ai`). A tenant is provisioned in one region, and every tenant-specific URL, hostname, or IP address reflects it. See the "Hosting regions" table in [Create a C1 tenant](/product/how-to/qs-set-up-c1) for the canonical explainer — link there rather than re-explaining the concept on other pages. +C1.ai runs two hosting options — a **default instance** (`conductor.one`) and an **EU data residency instance** (`c1eu.ai`). A tenant is provisioned in one region, and every tenant-specific URL, hostname, or IP address reflects it. See the "Hosting regions" table in [Create a C1.ai tenant](/product/how-to/qs-set-up-c1) for the canonical explainer — link there rather than re-explaining the concept on other pages. Anywhere a region-specific value appears, use one of the two treatments below based on how the value is used — not on which section of the docs it's in. @@ -229,9 +229,9 @@ Anywhere a region-specific value appears, use one of the two treatments below ba - EU data residency instance: `https://accounts.c1eu.ai/auth/callback` ``` -Lead into the pair with wording that tells the reader how to choose — "whichever matches your C1 tenant's domain" — rather than assuming they already know which hosting option they're on. This applies even when the value is tenant-specific (contains a placeholder like `` or `YOUR_DOMAIN`): show both domain suffixes, not just `conductor.one`. +Lead into the pair with wording that tells the reader how to choose — "whichever matches your C1.ai tenant's domain" — rather than assuming they already know which hosting option they're on. This applies even when the value is tenant-specific (contains a placeholder like `` or `YOUR_DOMAIN`): show both domain suffixes, not just `conductor.one`. -Don't use this pattern for a value the reader copies directly from their own C1 account (for example, an MCP server URL shown on an "AI connections" page) — the product already displays the tenant's real, region-correct value, so there's nothing to disambiguate. +Don't use this pattern for a value the reader copies directly from their own C1.ai account (for example, an MCP server URL shown on an "AI connections" page) — the product already displays the tenant's real, region-correct value, so there's nothing to disambiguate. **Reference and example-heavy pages** (API docs, CLI docs, service-principal/workload-federation guides) where `conductor.one` appears repeatedly inside code blocks or curl examples — don't rewrite every example. Add one callout near the section the examples belong to instead: @@ -255,15 +255,15 @@ Don't use this pattern for a value the reader copies directly from their own C1 ## Product name -Always use **C1** to refer to the product and company in prose. Do not use "ConductorOne" in new documentation. +Always use **C1.ai** to refer to the product and company in prose. Do not use "ConductorOne" in new documentation. **Marketing website:** The marketing website is **c1.ai** — use this for any links to the public marketing site. Do not use `conductorone.com` for marketing links. -**Exceptions — never change these to C1:** +**Exceptions — never change these to C1.ai:** | What | Examples | | :--- | :--- | -| Product and tenant URLs | `conductor.one`, tenant URLs like `example.conductor.one` | +| Product and tenant URLs | `conductor.one`, tenant URLs like `example.conductor.one`, and `c1eu.ai` (the EU data-residency domain) | | File and directory paths generated by tools | `~/.conductorone/config.yaml` | | Code identifiers | Environment variables (`CONDUCTORONE_CLIENT_ID`), package names, binary names | | GitHub organization in URLs | `github.com/ConductorOne/...` | @@ -272,14 +272,14 @@ When in doubt: if a user would type it into a terminal or config file, leave it ## Common Mistakes to Avoid -- **Hedging verbs**: "helps you to," "can help," "is designed to," "allows you to" — use direct verbs instead ("lets you," "C1 does X") +- **Hedging verbs**: "helps you to," "can help," "is designed to," "allows you to" — use direct verbs instead ("lets you," "C1.ai does X") - **Feature-first openers**: "Campaign templates are a feature that allows..." → lead with what the reader can do instead - **Celebrating task completion**: "That's it!", "Done.", "You're all set!" → state the outcome - **Multi-clause sentences serving too many stakeholders at once** — split or cut - **Editorializing**: "it's important to note," "it's worth mentioning," "please note" - **Promotional language**: "powerful," "robust," "seamless," "innovative" - **Excessive conjunctions**: "moreover," "furthermore," "additionally" -- **Using "ConductorOne"** instead of "C1" in prose +- **Using "ConductorOne"** instead of "C1.ai" in prose - **Using "bool"** — use "Boolean" - **Title case in headings** — sentence case only - **Context-free headings** like "FAQ" or "Related" — always include the subject ("Frequently asked questions about automations") diff --git a/.claude/skills/rap-documentation.md b/.claude/skills/rap-documentation.md index 7b2baafa..31977649 100644 --- a/.claude/skills/rap-documentation.md +++ b/.claude/skills/rap-documentation.md @@ -120,9 +120,9 @@ RAP files target LLM agents, not humans. Write differently than human-facing doc **Example contrast:** -Human docs: "The Baton connector framework solves this elegantly: you write one integration, and C1 handles the rest." +Human docs: "The Baton connector framework solves this elegantly: you write one integration, and C1.ai handles the rest." -RAP docs: "A connector translates access data from any system into C1's common format." +RAP docs: "A connector translates access data from any system into C1.ai's common format." The human version has warmth and sells the benefit. The RAP version states the fact. Both are correct; they serve different audiences. diff --git a/README.md b/README.md index 8c71663c..46d5b94a 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ -# C1 documentation +# C1.ai documentation -Welcome to the official repository for [C1 documentation](https://www.conductorone.com/docs)! +Welcome to the official repository for [C1.ai documentation](https://www.conductorone.com/docs)! We believe that great documentation is a community effort. This repository contains the source files for our docs site, and we’re excited to open it up for public contributions. Whether you've found a typo, a broken link, or have a suggestion for a new guide, we welcome your input. @@ -20,9 +20,9 @@ If you have larger changes or want to work locally: ## 📝 Review process -Every contribution, no matter how small, helps improve the experience for all C1 users. So thank you! +Every contribution, no matter how small, helps improve the experience for all C1.ai users. So thank you! -Once you submit a pull request, the **C1 documentation team** will review your suggestions. We may ask for clarification or make minor adjustments to ensure consistency with our style guide. Once approved, we’ll merge your changes and they’ll be live on the site shortly after! +Once you submit a pull request, the **C1.ai documentation team** will review your suggestions. We may ask for clarification or make minor adjustments to ensure consistency with our style guide. Once approved, we’ll merge your changes and they’ll be live on the site shortly after! ## 🤖 Writing with Claude diff --git a/conductorone-api/api.mdx b/conductorone-api/api.mdx index 346fcd00..23bcaa39 100644 --- a/conductorone-api/api.mdx +++ b/conductorone-api/api.mdx @@ -1,20 +1,20 @@ --- -title: Introducing C1's API -og:title: Introducing C1's API - C1 -og:description: The C1 API can be used to access data, automate tasks, and create integrations. -description: The C1 API can be used to access data, automate tasks, and create integrations. -sidebarTitle: "C1 API and keys" +title: Introducing C1.ai's API +og:title: Introducing C1.ai's API - C1.ai +og:description: The C1.ai API can be used to access data, automate tasks, and create integrations. +description: The C1.ai API can be used to access data, automate tasks, and create integrations. +sidebarTitle: "C1.ai API and keys" --- -The C1 application programming interface (API) is a set of rules that defines how C1 can communicate with other software programs. The C1 API lets developers access C1 data and functionality, automate workflows, and connect C1 to other tools and interfaces. +The C1.ai application programming interface (API) is a set of rules that defines how C1.ai can communicate with other software programs. The C1.ai API lets developers access C1.ai data and functionality, automate workflows, and connect C1.ai to other tools and interfaces. ## Create a personal API key -Create a personal API key to use when working with the C1 API. +Create a personal API key to use when working with the C1.ai API. - In the C1 web app, open your profile menu and select **API keys**. + In the C1.ai web app, open your profile menu and select **API keys**. Click **Create credential**. @@ -46,10 +46,10 @@ Your new API key is created and the client ID and client secret are shown. Caref The API key is added to list of your personal API clients, and its client ID and usage data for the key are shown. If needed, you can delete the API key from this page. -## View and manage all API keys for your C1 tenant +## View and manage all API keys for your C1.ai tenant -Only users with the **Super Administrator** [user role](/product/admin/user-roles) in C1 can view and manage API keys other than their own. +Only users with the **Super Administrator** [user role](/product/admin/user-roles) in C1.ai can view and manage API keys other than their own. diff --git a/conductorone-api/authenticate.mdx b/conductorone-api/authenticate.mdx index b212b3b6..87bdd760 100644 --- a/conductorone-api/authenticate.mdx +++ b/conductorone-api/authenticate.mdx @@ -1,199 +1,199 @@ ---- -title: How to authenticate requests -description: "To use the C1 API, you must authenticate your requests. This document guides you through the process of obtaining and utilizing an API key, as well as establishing an access token." ---- - -These examples use `conductor.one`. If your organization is on the EU data residency instance, substitute `c1eu.ai` in URLs, client IDs, and hostnames. - -## Step 1: Obtain an API key - -The first step in the process is to obtain your API key from C1: - - - -In the C1 app, navigate to the User's API Settings page by clicking your username at the bottom of the screen and selecting **AI & API**. - - -In the **API credentials** section of the page, click **Create credential**. - - -Enter a descriptive name for your API key. - - -Set the API key's lifespan. Select from 30 days, 90 days, or never expires. - - -If necessary, limit the source IPs the API key can be used from by entering one or more CIDR blocks in the **Allowed IPs** field. - - -Select the scope of permissions for the API key. You can choose either **Full Permissions** or select specific roles to assign to the API key. - - -Click **Create** to generate the API key. - - - -Your new key is created, and its Client ID and Client Secret are generated and displayed. Take note that the Client Secret is shown to you once, so make sure to securely store this information. - -On the API credentials table, you'll view the name and Client ID of each API key you've created, the key's expiration date (if relevant), the scope granted to the key, and its created on and last used dates. - -### Details about the Client ID and Client Secret - -The Client ID is a stable format that includes a random ID, the base hostname, and the use-case. It is represented in the format: `@/`. For example: `strange-hydra-68836@acme.conductor.one/pcc`. - -The Client Secret follows the format: `secret-token:conductorone.com:${base64url encoded JWK}`. It contains an `ed25519` private key that you may parse to get the private key. For example: - -```bash -secret-token:conductorone.com:v1:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5IiwieCI6IkMySEx5Y0d6eUhfZDQwcjJvejZoNkpqdndvRVFBZ0FTRVc2eDB6emh6Y2MiLCJkIjoiLTgzVkxXUVUtZVhQY0ZCWVhDb2NpU29XVmhrYnRXUm9zdkZUZ3JqcXNVbyJ9 -``` - -Remember to securely handle and store your Client ID and Client Secret. They play a critical role in the security and integrity of your interaction with our API. - -## Step 2: Determine your API root and token endpoint - -A crucial part of interacting with the C1 API involves determining the appropriate endpoints for your requests. Two key components in this process are your API root and the token endpoint. These can be inferred from your Client ID. - -### Extracting the hostname from the Client ID - - -Your Client ID is in the format `@/`. The hostname for your API client can be identified as the portion of your Client ID immediately following the `@` and preceding the `/`. - -For instance, for the Client ID `strange-hydra-68836@acme.conductor.one/pcc`, the hostname is `acme.conductor.one`. - -### Identifying the token endpoint - -With the hostname in hand, the token endpoint can be determined. It resides under the hostname at the path `/auth/v1/token`. So for the example Client ID above, the token endpoint is `https://acme.conductor.one/auth/v1/token`. - -### Identifying the API root - -Similar to the token endpoint, the API root is also located under the hostname. It resides at the path `/api/v1`. In our example Client ID, the API root is `https://acme.conductor.one/api/v1`. - -## Step 3: Get an access token - -There are two methods available for obtaining an access token. Choose the one that best fits your needs. - -### Get a basic access token - -A basic access token can be obtained by utilizing your Client ID and Client Secret with the OAuth2 Token Endpoint. - -To achieve this: - -POST a request to Token Endpoint using the `application/x-www-form-urlencoded` content type. - -Include the following data in your request: - -- `grant_type=client_credentials` -- `client_id=${CLIENT_ID}` -- `client_secret=${CLIENT_SECRET}` - -You will receive a JSON response which includes an an `access_token`, `token_type`, and an `expires_in` value that indicates the number of seconds until the access token expires. - -Example JSON response: - -```json -{ - "access_token": "secret_access_token_value", - "token_type": "Bearer", - "expires_in": 600 -} -``` - -#### Example requests for a basic access token - -The examples below use placeholder values. Replace ``, ``, and `` with values from your own API credential (see Step 1) and the hostname extracted from your Client ID (see Step 2). - - -```bash curl -curl -X POST "https:///auth/v1/token" \ - -H "Content-Type: application/x-www-form-urlencoded" \ - --data-urlencode "grant_type=client_credentials" \ - --data-urlencode "client_id=" \ - --data-urlencode "client_secret=" -``` - -```python Python -import requests - -CLIENT_ID = "" -CLIENT_SECRET = "" -HOSTNAME = "" # for example, "acme.conductor.one" - -response = requests.post( - f"https://{HOSTNAME}/auth/v1/token", - data={ - "grant_type": "client_credentials", - "client_id": CLIENT_ID, - "client_secret": CLIENT_SECRET, - }, - headers={"Content-Type": "application/x-www-form-urlencoded"}, -) -response.raise_for_status() - -access_token = response.json()["access_token"] - -# Use the token in subsequent requests -api_response = requests.get( - f"https://{HOSTNAME}/api/v1/apps", - headers={"Authorization": f"Bearer {access_token}"}, -) -``` - - -### Get an access token using a Signed Client Assertion - -For a more secure authentication process, a JWT can be created and signed using the JWK private key derived from the parsed Client Secret. - -Here are the key requirements for the signed JWT: - -- The issuer (iss) should be set to the `${CLIENT_ID}` value. -- The subject (sub) should be set to the `${CLIENT_ID}` value. -- The audience (aud) should be set to the Tenant's Domain. -- The expiration time (exp) of the JWT must be within five minutes of the current time. Infinitely valid JWTs are not allowed. - -To authenticate using a signed client assertion, you should POST a request to `${TOKEN_ENDPOINT}` using the `application/x-www-form-urlencoded` content type with the following data: - -- `grant_type=client_credentials` -- `client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer` -- `client_id=${CLIENT_ID}` -- `client_assertion=${CLIENT_ASSERTION}` - -You will receive a JSON response which includes an `access_token`, `token_type`, and an `expires_in` value that indicates the number of seconds until the access token expires. - -Example JSON response: - -```json -{ - "access_token": "secret_access_token_value", - "token_type": "Bearer", - "expires_in": 600 -} -``` - - -Here's an example of creating a OAuth Token Source for this signing mechanism using Cone: [https://github.com/conductorone/cone/blob/main/pkg/client/token\_source.go](https://github.com/conductorone/cone/blob/main/pkg/client/token_source.go) - - -## Making requests to the API using an access token - -Once you have successfully obtained an access token, you are ready to make authenticated requests to the C1 API. - -Here's how to include the access token in your request: - -Set the `Authorization` HTTP header to `Bearer ${ACCESS_TOKEN}`. - -Example: - -```bash -GET /api/v1/endpoint HTTP/1.1 -Host: acme.conductor.one -Authorization: Bearer ${ACCESS_TOKEN} -``` -Remember to replace `${ACCESS_TOKEN}` with your actual access token. - -Keep in mind that your access token will expire after a period of time (as indicated by the `expires_in` field in the JSON response when you obtained your access token). When this happens, any request you make with the expired access token will be denied. - -To avoid service interruption: - -- Track the `expires_in` time for your access token. -- Generate and implement a new access token before the `expires_in` time has passed. This will ensure continuous access to the C1 API. - +--- +title: How to authenticate requests +description: "To use the C1.ai API, you must authenticate your requests. This document guides you through the process of obtaining and utilizing an API key, as well as establishing an access token." +--- + +These examples use `conductor.one`. If your organization is on the EU data residency instance, substitute `c1eu.ai` in URLs, client IDs, and hostnames. + +## Step 1: Obtain an API key + +The first step in the process is to obtain your API key from C1.ai: + + + +In the C1.ai app, navigate to the User's API Settings page by clicking your username at the bottom of the screen and selecting **AI & API**. + + +In the **API credentials** section of the page, click **Create credential**. + + +Enter a descriptive name for your API key. + + +Set the API key's lifespan. Select from 30 days, 90 days, or never expires. + + +If necessary, limit the source IPs the API key can be used from by entering one or more CIDR blocks in the **Allowed IPs** field. + + +Select the scope of permissions for the API key. You can choose either **Full Permissions** or select specific roles to assign to the API key. + + +Click **Create** to generate the API key. + + + +Your new key is created, and its Client ID and Client Secret are generated and displayed. Take note that the Client Secret is shown to you once, so make sure to securely store this information. + +On the API credentials table, you'll view the name and Client ID of each API key you've created, the key's expiration date (if relevant), the scope granted to the key, and its created on and last used dates. + +### Details about the Client ID and Client Secret + +The Client ID is a stable format that includes a random ID, the base hostname, and the use-case. It is represented in the format: `@/`. For example: `strange-hydra-68836@acme.conductor.one/pcc`. + +The Client Secret follows the format: `secret-token:conductorone.com:${base64url encoded JWK}`. It contains an `ed25519` private key that you may parse to get the private key. For example: + +```bash +secret-token:conductorone.com:v1:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5IiwieCI6IkMySEx5Y0d6eUhfZDQwcjJvejZoNkpqdndvRVFBZ0FTRVc2eDB6emh6Y2MiLCJkIjoiLTgzVkxXUVUtZVhQY0ZCWVhDb2NpU29XVmhrYnRXUm9zdkZUZ3JqcXNVbyJ9 +``` + +Remember to securely handle and store your Client ID and Client Secret. They play a critical role in the security and integrity of your interaction with our API. + +## Step 2: Determine your API root and token endpoint + +A crucial part of interacting with the C1.ai API involves determining the appropriate endpoints for your requests. Two key components in this process are your API root and the token endpoint. These can be inferred from your Client ID. + +### Extracting the hostname from the Client ID + + +Your Client ID is in the format `@/`. The hostname for your API client can be identified as the portion of your Client ID immediately following the `@` and preceding the `/`. + +For instance, for the Client ID `strange-hydra-68836@acme.conductor.one/pcc`, the hostname is `acme.conductor.one`. + +### Identifying the token endpoint + +With the hostname in hand, the token endpoint can be determined. It resides under the hostname at the path `/auth/v1/token`. So for the example Client ID above, the token endpoint is `https://acme.conductor.one/auth/v1/token`. + +### Identifying the API root + +Similar to the token endpoint, the API root is also located under the hostname. It resides at the path `/api/v1`. In our example Client ID, the API root is `https://acme.conductor.one/api/v1`. + +## Step 3: Get an access token + +There are two methods available for obtaining an access token. Choose the one that best fits your needs. + +### Get a basic access token + +A basic access token can be obtained by utilizing your Client ID and Client Secret with the OAuth2 Token Endpoint. + +To achieve this: + +POST a request to Token Endpoint using the `application/x-www-form-urlencoded` content type. + +Include the following data in your request: + +- `grant_type=client_credentials` +- `client_id=${CLIENT_ID}` +- `client_secret=${CLIENT_SECRET}` + +You will receive a JSON response which includes an an `access_token`, `token_type`, and an `expires_in` value that indicates the number of seconds until the access token expires. + +Example JSON response: + +```json +{ + "access_token": "secret_access_token_value", + "token_type": "Bearer", + "expires_in": 600 +} +``` + +#### Example requests for a basic access token + +The examples below use placeholder values. Replace ``, ``, and `` with values from your own API credential (see Step 1) and the hostname extracted from your Client ID (see Step 2). + + +```bash curl +curl -X POST "https:///auth/v1/token" \ + -H "Content-Type: application/x-www-form-urlencoded" \ + --data-urlencode "grant_type=client_credentials" \ + --data-urlencode "client_id=" \ + --data-urlencode "client_secret=" +``` + +```python Python +import requests + +CLIENT_ID = "" +CLIENT_SECRET = "" +HOSTNAME = "" # for example, "acme.conductor.one" + +response = requests.post( + f"https://{HOSTNAME}/auth/v1/token", + data={ + "grant_type": "client_credentials", + "client_id": CLIENT_ID, + "client_secret": CLIENT_SECRET, + }, + headers={"Content-Type": "application/x-www-form-urlencoded"}, +) +response.raise_for_status() + +access_token = response.json()["access_token"] + +# Use the token in subsequent requests +api_response = requests.get( + f"https://{HOSTNAME}/api/v1/apps", + headers={"Authorization": f"Bearer {access_token}"}, +) +``` + + +### Get an access token using a Signed Client Assertion + +For a more secure authentication process, a JWT can be created and signed using the JWK private key derived from the parsed Client Secret. + +Here are the key requirements for the signed JWT: + +- The issuer (iss) should be set to the `${CLIENT_ID}` value. +- The subject (sub) should be set to the `${CLIENT_ID}` value. +- The audience (aud) should be set to the Tenant's Domain. +- The expiration time (exp) of the JWT must be within five minutes of the current time. Infinitely valid JWTs are not allowed. + +To authenticate using a signed client assertion, you should POST a request to `${TOKEN_ENDPOINT}` using the `application/x-www-form-urlencoded` content type with the following data: + +- `grant_type=client_credentials` +- `client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer` +- `client_id=${CLIENT_ID}` +- `client_assertion=${CLIENT_ASSERTION}` + +You will receive a JSON response which includes an `access_token`, `token_type`, and an `expires_in` value that indicates the number of seconds until the access token expires. + +Example JSON response: + +```json +{ + "access_token": "secret_access_token_value", + "token_type": "Bearer", + "expires_in": 600 +} +``` + + +Here's an example of creating a OAuth Token Source for this signing mechanism using Cone: [https://github.com/conductorone/cone/blob/main/pkg/client/token\_source.go](https://github.com/conductorone/cone/blob/main/pkg/client/token_source.go) + + +## Making requests to the API using an access token + +Once you have successfully obtained an access token, you are ready to make authenticated requests to the C1.ai API. + +Here's how to include the access token in your request: + +Set the `Authorization` HTTP header to `Bearer ${ACCESS_TOKEN}`. + +Example: + +```bash +GET /api/v1/endpoint HTTP/1.1 +Host: acme.conductor.one +Authorization: Bearer ${ACCESS_TOKEN} +``` +Remember to replace `${ACCESS_TOKEN}` with your actual access token. + +Keep in mind that your access token will expire after a period of time (as indicated by the `expires_in` field in the JSON response when you obtained your access token). When this happens, any request you make with the expired access token will be denied. + +To avoid service interruption: + +- Track the `expires_in` time for your access token. +- Generate and implement a new access token before the `expires_in` time has passed. This will ensure continuous access to the C1.ai API. + diff --git a/conductorone-api/pagination.mdx b/conductorone-api/pagination.mdx index 30293f7e..5f5bf94a 100644 --- a/conductorone-api/pagination.mdx +++ b/conductorone-api/pagination.mdx @@ -1,83 +1,83 @@ ---- -title: Pagination in the C1 API -description: "When making `LIST` or `SEARCH` requests to the C1 API, use the `page_size` and `page_token` parameters to navigate through the list of results." ---- - -These examples use `conductor.one`. If your organization is on the EU data residency instance, substitute `c1eu.ai` in URLs, client IDs, and hostnames. - -## Using page\_size - -Include the `page_size` parameter to tell the API how many search or list results to show on each page. - -**`page_size` accepts a number between 10 and 100.** - -- If you enter a number smaller than 10, the system will return 10 results per page. -- If you enter a number larger than 100, the system will return 100 results per page. -- The default value is 25. - -## Using page\_token - -If your query returns more results than will fit on one page of the size you specified with `page_size`, you'll see a unique `nextPageToken` value at the bottom of the response. Include this value with the `page_token` parameter in your next request to see the next page of results. - -You do not need to include `page_token` in your initial request (or you can include it but leave it empty), but you must do so for each subsequent request. - -Here's a simplified example of using `page_token` to navigate a list of results: - -```bash First request - -curl --request GET \ - --url 'https://example.conductor.one/api/v1/apps/sample/entitlements?page_size=50' -``` - -```json First response -{ - "list": [ - { - "appEntitlement": { - // List of 50 app entitlements with their details. - } - ], - "nextPageToken": "samplepaggetoken1" -} -``` - - -```bash Second request - -curl --request GET \ - --url 'https://example.conductor.one/api/v1/apps/sample/entitlements?page_size=50&page_token=samplepagetoken1' -``` - - -**Note:** For this `GET` example, the `page_size` and `page_token` are included in the query. For `POST` requests, `page_size` and `page_token` are included in the body instead. - - -```json Second response -"list": [ - { - "appEntitlement": { - // List of 50 more app entitlements with their details. - } - ], - "nextPageToken": "samplepaggetoken2" -} -``` -```bash Third request - -curl --request GET \ - --url 'https://example.conductor.one/api/v1/apps/sample/entitlements?page_size=50&page_token=samplepagetoken2' -``` -```json Third response -{ - "list": [ - { - "appEntitlement": { - // List of 26 more app entitlements with their details. - } - ], - "nextPageToken": "" - // An empty nextPageToken is printed in the third response because the user has reached the end of the list of results. -} -``` - - +--- +title: Pagination in the C1.ai API +description: "When making `LIST` or `SEARCH` requests to the C1.ai API, use the `page_size` and `page_token` parameters to navigate through the list of results." +--- + +These examples use `conductor.one`. If your organization is on the EU data residency instance, substitute `c1eu.ai` in URLs, client IDs, and hostnames. + +## Using page\_size + +Include the `page_size` parameter to tell the API how many search or list results to show on each page. + +**`page_size` accepts a number between 10 and 100.** + +- If you enter a number smaller than 10, the system will return 10 results per page. +- If you enter a number larger than 100, the system will return 100 results per page. +- The default value is 25. + +## Using page\_token + +If your query returns more results than will fit on one page of the size you specified with `page_size`, you'll see a unique `nextPageToken` value at the bottom of the response. Include this value with the `page_token` parameter in your next request to see the next page of results. + +You do not need to include `page_token` in your initial request (or you can include it but leave it empty), but you must do so for each subsequent request. + +Here's a simplified example of using `page_token` to navigate a list of results: + +```bash First request + +curl --request GET \ + --url 'https://example.conductor.one/api/v1/apps/sample/entitlements?page_size=50' +``` + +```json First response +{ + "list": [ + { + "appEntitlement": { + // List of 50 app entitlements with their details. + } + ], + "nextPageToken": "samplepaggetoken1" +} +``` + + +```bash Second request + +curl --request GET \ + --url 'https://example.conductor.one/api/v1/apps/sample/entitlements?page_size=50&page_token=samplepagetoken1' +``` + + +**Note:** For this `GET` example, the `page_size` and `page_token` are included in the query. For `POST` requests, `page_size` and `page_token` are included in the body instead. + + +```json Second response +"list": [ + { + "appEntitlement": { + // List of 50 more app entitlements with their details. + } + ], + "nextPageToken": "samplepaggetoken2" +} +``` +```bash Third request + +curl --request GET \ + --url 'https://example.conductor.one/api/v1/apps/sample/entitlements?page_size=50&page_token=samplepagetoken2' +``` +```json Third response +{ + "list": [ + { + "appEntitlement": { + // List of 26 more app entitlements with their details. + } + ], + "nextPageToken": "" + // An empty nextPageToken is printed in the third response because the user has reached the end of the list of results. +} +``` + + diff --git a/connector-template.mdx b/connector-template.mdx index a93c2a6c..38e2a24b 100644 --- a/connector-template.mdx +++ b/connector-template.mdx @@ -1,8 +1,8 @@ --- title: "Set up a [Connector Name] connector" og:title: "Set up a [Connector Name] connector" -description: "C1 provides identity governance and just-in-time provisioning for [App Name]. Integrate your [App Name] instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access." -og:description: "C1 provides identity governance and just-in-time provisioning for [App Name]. Integrate your [App Name] instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access." +description: "C1.ai provides identity governance and just-in-time provisioning for [App Name]. Integrate your [App Name] instance with C1.ai to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access." +og:description: "C1.ai provides identity governance and just-in-time provisioning for [App Name]. Integrate your [App Name] instance with C1.ai to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access." sidebarTitle: "[Connector Name]" --- @@ -66,7 +66,7 @@ To configure the [App Name] connector, you need [specific permission level] perm - `scope:name` - [Brief description] - The **scope:name** scope is used by C1 when automatically provisioning and deprovisioning access. **If you do not want C1 to perform these tasks, do not give your token this scope.** + The **scope:name** scope is used by C1.ai when automatically provisioning and deprovisioning access. **If you do not want C1.ai to perform these tasks, do not give your token this scope.** 5. Click **[Generate/Create]** @@ -86,11 +86,11 @@ To configure the [App Name] connector, you need [specific permission level] perm - Follow these instructions to use a built-in, no-code connector hosted by C1. + Follow these instructions to use a built-in, no-code connector hosted by C1.ai. - 1. In C1, navigate to **Apps** > **Connectors** and click **Add connector**. + 1. In C1.ai, navigate to **Apps** > **Connectors** and click **Add connector**. 2. Search for **[Connector Name]** and click **Add**. @@ -123,7 +123,7 @@ To configure the [App Name] connector, you need [specific permission level] perm - Click **Save**. C1 will begin syncing data from [App Name]. + Click **Save**. C1.ai will begin syncing data from [App Name]. To verify the sync is working: 1. Navigate to **Apps** > **Connectors**. @@ -132,7 +132,7 @@ To configure the [App Name] connector, you need [specific permission level] perm - **Done.** Your [App Name] connector is now pulling access data into C1. + **Done.** Your [App Name] connector is now pulling access data into C1.ai. @@ -140,9 +140,9 @@ To configure the [App Name] connector, you need [specific permission level] perm - 1. In C1, navigate to **Apps** > **Connectors** and click **Add connector**. + 1. In C1.ai, navigate to **Apps** > **Connectors** and click **Add connector**. 2. Search for **[Connector Name]** and click **Add**. - 3. Choose how you want to set up your [App Name] app in C1 (see cloud-hosted instructions above for details). + 3. Choose how you want to set up your [App Name] app in C1.ai (see cloud-hosted instructions above for details). 4. Set the app owner. 5. Click **Save**. 6. Make note of the **Client ID** and **Client Secret** that are displayed. You'll need these values in the next step. @@ -242,7 +242,7 @@ To configure the [App Name] connector, you need [specific permission level] perm - **Done.** Your [App Name] connector is now pulling access data into C1. + **Done.** Your [App Name] connector is now pulling access data into C1.ai. diff --git a/developer/baton-sdk.mdx b/developer/baton-sdk.mdx index 9e958a89..5ad944a2 100644 --- a/developer/baton-sdk.mdx +++ b/developer/baton-sdk.mdx @@ -218,7 +218,7 @@ type CredentialManager interface { } ``` -Returns plaintext credentials; the SDK encrypts them before sending to C1. +Returns plaintext credentials; the SDK encrypts them before sending to C1.ai. Enables `CAPABILITY_CREDENTIAL_ROTATION`. diff --git a/developer/build-connector.mdx b/developer/build-connector.mdx index 3ab8cfd4..e1a8ea97 100644 --- a/developer/build-connector.mdx +++ b/developer/build-connector.mdx @@ -1,12 +1,12 @@ --- title: Build a new Baton connector -og:title: Build a new Baton connector - C1 -og:description: If you need to connect C1 to a homegrown or backoffice piece of infrastructure, you can build your own connector with the Baton software development kit (SDK). +og:title: Build a new Baton connector - C1.ai +og:description: If you need to connect C1.ai to a homegrown or backoffice piece of infrastructure, you can build your own connector with the Baton software development kit (SDK). description: Use the Baton software development kit to build your own connector if a pre-built cloud connector isn't available. sidebarTitle: "Build a new connector" --- -If you need to connect C1 to a homegrown or backoffice piece of infrastructure, or to software that doesn't yet have a [pre-built connector](https://github.com/conductorone), you can build your own connector with the Baton software development kit (SDK). Once built, these connectors can be integrated directly with C1. +If you need to connect C1.ai to a homegrown or backoffice piece of infrastructure, or to software that doesn't yet have a [pre-built connector](https://github.com/conductorone), you can build your own connector with the Baton software development kit (SDK). Once built, these connectors can be integrated directly with C1.ai. Check out our tutorial video to learn how to build your own Baton connector: diff --git a/developer/c1-api.mdx b/developer/c1-api.mdx index a5acd77e..a8c19d24 100644 --- a/developer/c1-api.mdx +++ b/developer/c1-api.mdx @@ -1,12 +1,12 @@ --- -title: "C1 API integration reference" -sidebarTitle: "C1 API" -description: "How connectors communicate with the C1 platform in daemon mode." +title: "C1.ai API integration reference" +sidebarTitle: "C1.ai API" +description: "How connectors communicate with the C1.ai platform in daemon mode." --- -When running in daemon mode, connectors communicate with C1 via gRPC. The SDK handles all API communication - connector developers implement interfaces, the SDK calls your code when tasks arrive. +When running in daemon mode, connectors communicate with C1.ai via gRPC. The SDK handles all API communication - connector developers implement interfaces, the SDK calls your code when tasks arrive. -This document describes the C1 APIs that connectors use internally. You don't call these APIs directly; the SDK manages them. +This document describes the C1.ai APIs that connectors use internally. You don't call these APIs directly; the SDK manages them. ## Communication architecture @@ -78,7 +78,7 @@ type SyncTask struct { } ``` -**Connector produces:** c1z file uploaded to C1 +**Connector produces:** c1z file uploaded to C1.ai ### Grant task @@ -112,7 +112,7 @@ type CreateAccountTask struct { } ``` -**Returns to C1:** Created account, credentials (encrypted by SDK) +**Returns to C1.ai:** Created account, credentials (encrypted by SDK) ### DeleteResource task @@ -132,7 +132,7 @@ type RotateCredentialTask struct { } ``` -**Returns to C1:** New credentials (encrypted by SDK) +**Returns to C1.ai:** New credentials (encrypted by SDK) ## Task lifecycle @@ -169,7 +169,7 @@ var ( ) ``` -C1 can adjust heartbeat interval per-task. If heartbeats stop, the task may be reassigned to another connector instance. +C1.ai can adjust heartbeat interval per-task. If heartbeats stop, the task may be reassigned to another connector instance. ### Task completion @@ -233,13 +233,13 @@ Connectors authenticate using OAuth2 client credentials: ``` The SDK handles: -- Token acquisition from C1's OAuth endpoint +- Token acquisition from C1.ai's OAuth endpoint - Token refresh before expiration - Token injection into request metadata ### Host identification -Connectors identify themselves to C1: +Connectors identify themselves to C1.ai: ```go hostId := os.Getenv("BATON_HOST_ID") @@ -248,7 +248,7 @@ if hostId == "" { } ``` -This helps C1 track which host is running which connector instance. +This helps C1.ai track which host is running which connector instance. ## Error handling @@ -266,12 +266,12 @@ taskMaximumHeartbeatFailures = 10 ### Error flow -| Connector Error | SDK Handling | C1 Action | +| Connector Error | SDK Handling | C1.ai Action | |-----------------|--------------|---------------------| | Temporary failure | Retry with backoff | Task stays queued | | Permanent failure | FinishTask(FAILED) | Task marked failed | | Heartbeat timeout | Task abandoned | Reassign to other instance | -| Cancelled by C1 | Stop processing | Task cancelled | +| Cancelled by C1.ai | Stop processing | Task cancelled | ### Annotations for error context @@ -318,7 +318,7 @@ Debug output includes: |---------|--------------|----------| | `authentication error` | Invalid client credentials | Verify client-id/secret | | `task heartbeat failed` | Processing too slow | Optimize or add heartbeats | -| `connection refused` | Network/firewall issue | Check connectivity to C1 | +| `connection refused` | Network/firewall issue | Check connectivity to C1.ai | | `task cancelled` | Task timeout or user cancel | Check task duration | | `upload failed` | Large c1z or network issue | Check file size, retry | diff --git a/developer/community.mdx b/developer/community.mdx index b85337c2..98684826 100644 --- a/developer/community.mdx +++ b/developer/community.mdx @@ -41,7 +41,7 @@ Include: |---------|--------------|---------| | GitHub Issues | Days | Bugs, connector feature requests | | GitHub Discussions | Days | Questions, how-to help | -| C1 Support | Hours | Production issues (customers), product feature requests | +| C1.ai Support | Hours | Production issues (customers), product feature requests | ## Reporting issues @@ -157,12 +157,12 @@ All complaints will be reviewed and investigated promptly and fairly. ### Decision making -The Baton ecosystem is maintained by C1 with community input. +The Baton ecosystem is maintained by C1.ai with community input. | Decision type | Who decides | |--------------|-------------| -| SDK changes | C1 team | -| New connectors (C1 org) | C1 team | +| SDK changes | C1.ai team | +| New connectors (C1.ai org) | C1.ai team | | New connectors (your org) | You | | Feature requests | Maintainers of affected repo | diff --git a/developer/concepts.mdx b/developer/concepts.mdx index f92c2e12..5f4e716c 100644 --- a/developer/concepts.mdx +++ b/developer/concepts.mdx @@ -6,13 +6,13 @@ description: "Build a correct mental model of the resource/entitlement/grant gra Every target system has its own vocabulary (teams vs groups, roles vs permission sets, projects vs workspaces). This diversity is a strength - each system evolved for its specific purpose. But it creates a challenge: how do you get unified visibility across all of them? -Baton solves this by normalizing every system into a consistent shape so C1 can ask one question across all systems: who has access to what? Without this normalization, each system would be an island - auditors would see chaos, and access reviews would require expert knowledge of every platform. +Baton solves this by normalizing every system into a consistent shape so C1.ai can ask one question across all systems: who has access to what? Without this normalization, each system would be an island - auditors would see chaos, and access reviews would require expert knowledge of every platform. The minimal "connector surface area" is expressed through the SDK's `ResourceSyncer` interface: list resources, list entitlements, list grants. ## The access graph -Your connector produces an access graph that powers access reviews, certification campaigns, provisioning workflows, and compliance reporting. This single data structure drives everything C1 does. The graph has three main node/edge types: +Your connector produces an access graph that powers access reviews, certification campaigns, provisioning workflows, and compliance reporting. This single data structure drives everything C1.ai does. The graph has three main node/edge types: ```mermaid flowchart LR @@ -41,7 +41,7 @@ This is not a theoretical model: these are concrete protobuf types and services Most access management systems flatten everything into a single list. Baton takes a different approach: resources can have parent-child relationships. This preserves the natural structure of your target systems. -Consider GitHub: organizations contain repositories, repositories have branches. Or AWS: accounts contain services, services have resources. When your connector models these hierarchies, C1 can: +Consider GitHub: organizations contain repositories, repositories have branches. Or AWS: accounts contain services, services have resources. When your connector models these hierarchies, C1.ai can: - Show access in context (this role applies to *this* project, not globally) - Enable scoped access reviews (review all access within a single org unit) @@ -51,7 +51,7 @@ You express hierarchy through the `parentResourceID` parameter in your `List()` ## Resource types and traits -Every resource has a **resource type** (string id) and can declare **traits** that tell C1 how to interpret it. Traits let C1 understand *what kind of thing* a resource is, even when different systems call it different names. +Every resource has a **resource type** (string id) and can declare **traits** that tell C1.ai how to interpret it. Traits let C1.ai understand *what kind of thing* a resource is, even when different systems call it different names. ```go var userResourceType = &v2.ResourceType{ @@ -69,7 +69,7 @@ The trait enum includes: - `TRAIT_SECRET` - `TRAIT_ROLE_SCOPE` -Traits are optional for custom resource types, but they unlock powerful features. When you mark a resource with `TRAIT_USER`, C1 knows it can correlate that resource with users from other systems, display it in user-centric views, and apply user-specific policies. +Traits are optional for custom resource types, but they unlock powerful features. When you mark a resource with `TRAIT_USER`, C1.ai knows it can correlate that resource with users from other systems, display it in user-centric views, and apply user-specific policies. | Trait | Use for | |-------|---------| @@ -97,7 +97,7 @@ One resource can offer multiple entitlements. A GitHub repository might offer: r #### Entitlement purpose -Entitlements have a `purpose` field that tells C1 how to interpret them: +Entitlements have a `purpose` field that tells C1.ai how to interpret them: | Purpose | Use For | Example | |---------|---------|---------| @@ -154,7 +154,7 @@ Stage 4: Grants() ### The sync pipeline -When a connector runs, data flows through several stages. The clean separation between what you control and what C1 controls makes the system reliable and testable: +When a connector runs, data flows through several stages. The clean separation between what you control and what C1.ai controls makes the system reliable and testable: ```mermaid flowchart LR @@ -168,16 +168,16 @@ flowchart LR 1. **Fetch** - Your connector calls the external API 2. **Transform** - Your connector creates Resource/Entitlement/Grant objects 3. **Output** - SDK writes objects to a .c1z file (gzip-compressed SQLite) -4. **Ingest** - C1's sync service reads the .c1z file +4. **Ingest** - C1.ai's sync service reads the .c1z file 5. **Uplift** - Raw connector records become domain objects (Apps, Resources, Grants) **What you control:** Steps 1-3. Your connector fetches, transforms, and outputs. -**What C1 controls:** Steps 4-5. The sync service and uplift process. +**What C1.ai controls:** Steps 4-5. The sync service and uplift process. ### ID correlation -C1 needs to know whether a resource in this sync is the same resource from a previous sync. This is where the `RawId` annotation matters. +C1.ai needs to know whether a resource in this sync is the same resource from a previous sync. This is where the `RawId` annotation matters. When you build a resource, include its external system ID: @@ -197,7 +197,7 @@ The `RawId` annotation carries the external system's identifier through the pipe - **Sync storage**: Stored as `external_id` on the connector record - **Domain objects**: Tracked in `source_connector_ids` map -This enables C1 to: +This enables C1.ai to: - Correlate resources across syncs (same ID = same resource) - Track which connector discovered which resource - Support pre-sync reservation patterns @@ -206,7 +206,7 @@ This enables C1 to: ### ID vocabulary -These terms appear throughout C1 when discussing identity correlation: +These terms appear throughout C1.ai when discussing identity correlation: | Term | Where it appears | Purpose | |------|-----------------|---------| @@ -220,7 +220,7 @@ The flow is: `RawId` (connector) -> `external_id` (sync) -> `source_connector_id ## Modeling decisions -Your modeling choices expand or constrain what your organization can do with access control. Two connectors can both be "correct" and still produce very different experiences in C1: +Your modeling choices expand or constrain what your organization can do with access control. Two connectors can both be "correct" and still produce very different experiences in C1.ai: - **Entitlement granularity** - Fine-grained (read/write/admin): more precision in reviews and provisioning, more total grants and API calls. @@ -261,7 +261,7 @@ Connectors can run in different modes: | Mode | Trigger | Behavior | |------|---------|----------| | **One-shot** | No `--client-id` | Run, sync to file, exit | -| **Daemon** | `--client-id` provided | Connect to C1, process tasks continuously | +| **Daemon** | `--client-id` provided | Connect to C1.ai, process tasks continuously | See [Deployment](/baton/deploy) for operational details on each mode. diff --git a/developer/config-schema.mdx b/developer/config-schema.mdx index ff9ff097..580741b7 100644 --- a/developer/config-schema.mdx +++ b/developer/config-schema.mdx @@ -27,8 +27,8 @@ Every connector automatically has these flags via the SDK. | Flag | Type | Description | |------|------|-------------| -| `--client-id` | string | C1 OAuth client ID (enables daemon mode) | -| `--client-secret` | string | C1 OAuth client secret | +| `--client-id` | string | C1.ai OAuth client ID (enables daemon mode) | +| `--client-secret` | string | C1.ai OAuth client secret | | `--skip-full-sync` | bool | Disable full sync in daemon mode | ### Provisioning operations diff --git a/developer/debugging.mdx b/developer/debugging.mdx index 90562d28..4db81ecb 100644 --- a/developer/debugging.mdx +++ b/developer/debugging.mdx @@ -228,7 +228,7 @@ details, _ := client.GetUsersWithDetails(ctx, userIDs) **Symptoms:** Daemon runs but never processes anything Check: -- Connector registered in C1 admin UI +- Connector registered in C1.ai admin UI - Sync scheduled - Correct connector ID @@ -263,7 +263,7 @@ Verify capabilities: ### Symptom -After running a sync, you see duplicate resources in C1: one created via Terraform/API and a separate one discovered by the connector. +After running a sync, you see duplicate resources in C1.ai: one created via Terraform/API and a separate one discovered by the connector. ### Causes diff --git a/developer/glossary.mdx b/developer/glossary.mdx index 9521d914..cb5f45d9 100644 --- a/developer/glossary.mdx +++ b/developer/glossary.mdx @@ -12,11 +12,11 @@ When in doubt about terminology, check here first. |------|------------| | **Baton** | The connector framework: Go SDK + individual connectors | | **baton-sdk** | Go library that handles sync orchestration, pagination, and connector runtime | -| **Connector** | A Go binary that syncs access control data from a third-party service into C1 | +| **Connector** | A Go binary that syncs access control data from a third-party service into C1.ai | | **c1z** | Compressed sync output file format (gzip SQLite) | -| **c1in** | C1 Integration Network - the overall connector ecosystem | -| **cone** | C1 CLI for access management | -| **conductorone-sdk-go** | Go SDK for C1 API integration | +| **c1in** | C1.ai Integration Network - the overall connector ecosystem | +| **cone** | C1.ai CLI for access management | +| **conductorone-sdk-go** | Go SDK for C1.ai API integration | | **Connector Hub** | User-facing name for the connector marketplace | | **Meta-connector** | Configuration-driven connector that maps external systems via YAML instead of Go code | | **baton-http** | Meta-connector for REST APIs using YAML configuration and CEL expressions | @@ -58,11 +58,11 @@ When in doubt about terminology, check here first. | Term | Definition | |------|------------| | **One-shot mode** | CLI mode: runs once, produces c1z file, exits (no --client-id) | -| **Daemon mode** | Long-running mode that polls C1 for tasks (requires --client-id and --client-secret) | -| **Hosted mode** | Connector run by C1 infrastructure on behalf of customers | +| **Daemon mode** | Long-running mode that polls C1.ai for tasks (requires --client-id and --client-secret) | +| **Hosted mode** | Connector run by C1.ai infrastructure on behalf of customers | | **Service mode** | Synonym for daemon mode | -| **Client credentials** | OAuth2 client ID and secret for authenticating connector to C1 | -| **Task polling** | Daemon mode behavior of periodically checking C1 for work | +| **Client credentials** | OAuth2 client ID and secret for authenticating connector to C1.ai | +| **Task polling** | Daemon mode behavior of periodically checking C1.ai for work | ## Provisioning operations @@ -81,13 +81,13 @@ When in doubt about terminology, check here first. | Term | Definition | |------|------------| -| **Sync** | Reading access data from a system into C1; produces .c1z file | -| **Uplift** | C1 process that transforms raw connector records into domain objects (Apps, Resources, Grants) | +| **Sync** | Reading access data from a system into C1.ai; produces .c1z file | +| **Uplift** | C1.ai process that transforms raw connector records into domain objects (Apps, Resources, Grants) | | **Provision** | Writing access changes back to a system (grant, revoke, create, delete) | | **Reconciliation** | Comparing actual access (from sync) to desired access (from policy) and correcting drift | | **external_id** | The identifier from an external system, stored with connector records during sync | | **source_connector_ids** | Map on domain objects tracking which connector provided which external ID | -| **ID Correlation** | Matching connector output to existing C1 objects using RawId and external_id | +| **ID Correlation** | Matching connector output to existing C1.ai objects using RawId and external_id | | **JIT Provisioning** | Just-In-Time provisioning - creating user account when first needed, not before | | **IdP** | Identity Provider - authoritative source of user identities (Okta, Azure AD, Google Workspace) | | **Source of Truth** | The system that authoritatively defines an entity (IdPs are typically source of truth for users) | diff --git a/developer/http-authoring.mdx b/developer/http-authoring.mdx index f0bb562f..a79338ba 100644 --- a/developer/http-authoring.mdx +++ b/developer/http-authoring.mdx @@ -4,7 +4,7 @@ sidebarTitle: "HTTP authoring" description: "Integrate any REST API without writing Go code. Configuration only." --- -Baton-HTTP is a configuration-driven connector that lets you write YAML instead of Go code. Instead of implementing the `ResourceSyncer` interface, you describe how to map an API to C1's resource model. Your ops team can own integrations directly — no engineering queue. +Baton-HTTP is a configuration-driven connector that lets you write YAML instead of Go code. Instead of implementing the `ResourceSyncer` interface, you describe how to map an API to C1.ai's resource model. Your ops team can own integrations directly — no engineering queue. ## Resources @@ -30,8 +30,8 @@ Baton-HTTP is a configuration-driven connector that lets you write YAML instead | `--config-path` | **(Required)** Path to the YAML configuration file | | `--validate-config-only` | Validate the configuration file and exit without running | | `--enable-command-actions` | Enable command actions (shell script execution) | -| `--client-id` | C1 client ID for service mode | -| `--client-secret` | C1 client secret for service mode | +| `--client-id` | C1.ai client ID for service mode | +| `--client-secret` | C1.ai client secret for service mode | Authentication credentials for the target API are configured in the YAML file using environment variable interpolation (e.g., `${API_TOKEN}`), not via command-line flags. @@ -183,7 +183,7 @@ auth: ## Resource type configuration -Resource types define the entities you want to sync. Each resource type specifies how to list resources and map API responses to C1 resources. +Resource types define the entities you want to sync. Each resource type specifies how to list resources and map API responses to C1.ai resources. ### Basic structure @@ -429,10 +429,10 @@ grants: ## Provisioning -Enable provisioning to grant and revoke access through C1. +Enable provisioning to grant and revoke access through C1.ai. -baton-http supports **access provisioning** (granting and revoking entitlements on existing accounts) through the `provisioning.grant` and `provisioning.revoke` request blocks below. It does not support **account provisioning** — creating new user accounts in the target system, or JIT-creating accounts when a grant fires. Account provisioning requires implementing the `AccountManager` interface in a custom Go connector built with the [Baton SDK](/developer/baton-sdk). Once such a connector exists, you can configure it in C1 following [Configure account provisioning](/product/admin/account-provisioning). +baton-http supports **access provisioning** (granting and revoking entitlements on existing accounts) through the `provisioning.grant` and `provisioning.revoke` request blocks below. It does not support **account provisioning** — creating new user accounts in the target system, or JIT-creating accounts when a grant fires. Account provisioning requires implementing the `AccountManager` interface in a custom Go connector built with the [Baton SDK](/developer/baton-sdk). Once such a connector exists, you can configure it in C1.ai following [Configure account provisioning](/product/admin/account-provisioning). ### Grant and revoke @@ -539,11 +539,11 @@ baton-http --config-path ./config.yaml \ ## Deploying to Kubernetes -### Step 1: Set up a new connector in C1 +### Step 1: Set up a new connector in C1.ai -In C1, navigate to **Connectors** > **Add connector**. +In C1.ai, navigate to **Connectors** > **Add connector**. Search for **Baton** and click **Add**. @@ -656,7 +656,7 @@ spec: ### Step 3: Deploy -Apply the configuration files to your Kubernetes cluster and verify the connector appears in C1 under **Applications** > **Managed apps**. +Apply the configuration files to your Kubernetes cluster and verify the connector appears in C1.ai under **Applications** > **Managed apps**. ## Example: GitHub integration diff --git a/developer/intro.mdx b/developer/intro.mdx index 32fa3ca4..d08fa339 100644 --- a/developer/intro.mdx +++ b/developer/intro.mdx @@ -8,9 +8,9 @@ What happens when an employee leaves your company but still has access to your p A **connector** answers the question: *who has access to what?* -C1 needs to know about users, groups, roles, and permissions across all your systems. But every system stores this information differently. Okta has users and groups. AWS has IAM roles and policies. Salesforce has profiles and permission sets. The Baton connector framework solves this: you write one integration, and C1 handles the rest. +C1.ai needs to know about users, groups, roles, and permissions across all your systems. But every system stores this information differently. Okta has users and groups. AWS has IAM roles and policies. Salesforce has profiles and permission sets. The Baton connector framework solves this: you write one integration, and C1.ai handles the rest. -A connector bridges this gap. It translates access data from any system into a common format that C1 understands. Once connected, you get unified visibility across your entire infrastructure. +A connector bridges this gap. It translates access data from any system into a common format that C1.ai understands. Once connected, you get unified visibility across your entire infrastructure. In Baton terms, a connector is a program that can: - **List resources** (users, groups, roles, apps, projects, etc.) @@ -48,7 +48,7 @@ Most people interact with connectors in two ways: Connectors do two things: -**Sync** (read): Pull access data from your systems into C1 +**Sync** (read): Pull access data from your systems into C1.ai - Who exists? What groups? What roles? - What permissions are available? - Who has what access right now? @@ -59,7 +59,7 @@ Connectors do two things: - **Create Account**: JIT (Just-In-Time) provisioning - **Delete Resource**: Remove accounts entirely -Together, sync and provision create a **reconciliation loop**: C1 sees what access exists (sync), compares it to what access *should* exist (policy), and corrects any drift (provision). Your access controls become self-healing. +Together, sync and provision create a **reconciliation loop**: C1.ai sees what access exists (sync), compares it to what access *should* exist (policy), and corrects any drift (provision). Your access controls become self-healing. ### The special role of identity providers @@ -74,7 +74,7 @@ When you connect an IdP, you're establishing the identity foundation that other ## Understanding the tools -Before diving into implementation, it helps to understand which tools do what. The C1 ecosystem has several SDKs and CLIs with different purposes. +Before diving into implementation, it helps to understand which tools do what. The C1.ai ecosystem has several SDKs and CLIs with different purposes. ### For connector developers @@ -101,14 +101,14 @@ baton grants -f sync.c1z # List grants baton entitlements -f sync.c1z # List entitlements ``` -### For C1 users (not connector development) +### For C1.ai users (not connector development) | Tool | Purpose | When to use | |------|---------|-------------| -| **cone** | CLI for C1 platform | Access requests, approvals, searches | -| **conductorone-sdk-go** | Go SDK for C1 API | Integrating with C1 platform | +| **cone** | CLI for C1.ai platform | Access requests, approvals, searches | +| **conductorone-sdk-go** | Go SDK for C1.ai API | Integrating with C1.ai platform | -**cone** is the C1 CLI for end-users and administrators. It handles access management workflows: +**cone** is the C1.ai CLI for end-users and administrators. It handles access management workflows: ```bash cone login # Authenticate to C1 @@ -123,7 +123,7 @@ cone task approve # Approve access requests | Build a new connector | `baton-sdk` | | Debug my connector's output | `baton` CLI | | Request or approve access | `cone` CLI | -| Build an app that uses C1 | `conductorone-sdk-go` | +| Build an app that uses C1.ai | `conductorone-sdk-go` | | Deploy a pre-built connector | The connector binary | @@ -136,8 +136,8 @@ When you build a connector, you produce a standalone binary (e.g., `baton-okta`, - **Embeds the SDK** - It's compiled with `baton-sdk`, not dependent on it at runtime - **Is self-contained** - No runtime dependencies except the target system's API -- **Runs independently** - You don't need any other C1 tools installed -- **Produces standard output** - A `.c1z` file that any C1 environment can consume +- **Runs independently** - You don't need any other C1.ai tools installed +- **Produces standard output** - A `.c1z` file that any C1.ai environment can consume ```bash # The connector IS the binary diff --git a/developer/postman.mdx b/developer/postman.mdx index 8f8a31e2..9ebd30c3 100644 --- a/developer/postman.mdx +++ b/developer/postman.mdx @@ -1,13 +1,13 @@ --- -title: C1's Postman instance -og:title: C1's Postman instance - C1 -og:description: Use Postman to send requests to the C1 API, inspect responses, and automate testing. -description: Use Postman to send requests to the C1 API, inspect responses, and automate testing. +title: C1.ai's Postman instance +og:title: C1.ai's Postman instance - C1.ai +og:description: Use Postman to send requests to the C1.ai API, inspect responses, and automate testing. +description: Use Postman to send requests to the C1.ai API, inspect responses, and automate testing. sidebarTitle: "Postman" --- Postman is an API development and testing platform that allows you to send requests to APIs, inspect the responses, and save requests for future use. Its ease of use makes it a popular tool among developers and testers for testing the functionality, performance, and security of APIs. -Visit [C1's Postman SDK on GitHub](https://github.com/conductorone/conductorone-sdk-postman) to get started using the C1 API in Postman. +Visit [C1.ai's Postman SDK on GitHub](https://github.com/conductorone/conductorone-sdk-postman) to get started using the C1.ai API in Postman. diff --git a/developer/provisioning.mdx b/developer/provisioning.mdx index 4444faa0..97cd8626 100644 --- a/developer/provisioning.mdx +++ b/developer/provisioning.mdx @@ -4,7 +4,7 @@ sidebarTitle: "Provisioning" description: "Grant and revoke access programmatically. Create accounts. Delete resources. This is where your connector becomes actionable." --- -Sync tells C1 what access exists. Provisioning lets C1 *change* access. +Sync tells C1.ai what access exists. Provisioning lets C1.ai *change* access. | Operation | What it does | |-----------|--------------| diff --git a/developer/recipes-id.mdx b/developer/recipes-id.mdx index fde22b20..e96843fc 100644 --- a/developer/recipes-id.mdx +++ b/developer/recipes-id.mdx @@ -22,7 +22,7 @@ Each recipe includes the problem, solution code, and rationale. | **Salesforce** | Salesforce ID | 18-char ID | `00e3h000000bRQAAA2` | | **Google Workspace** | Google Group ID | Variable | `00gjdgxs3x1h123` | -**Why this matters:** C1 uses these IDs to correlate resources across syncs. Using the wrong ID causes duplicate objects or failed correlations. +**Why this matters:** C1.ai uses these IDs to correlate resources across syncs. Using the wrong ID causes duplicate objects or failed correlations. **Key points:** - Azure AD has two IDs: Object ID (use this) and Application ID (client ID for OAuth) @@ -31,9 +31,9 @@ Each recipe includes the problem, solution code, and rationale. ## Setting RawId annotation -**Problem:** Ensure C1 can correlate your resources across syncs and match resources created via Terraform. +**Problem:** Ensure C1.ai can correlate your resources across syncs and match resources created via Terraform. -**What is RawId?** A string annotation containing the external system's native identifier. C1 uses this to match resources across syncs and to merge Terraform-created objects with connector-discovered ones. +**What is RawId?** A string annotation containing the external system's native identifier. C1.ai uses this to match resources across syncs and to merge Terraform-created objects with connector-discovered ones. **Solution:** Add the `RawId` annotation when building resources: diff --git a/developer/sdk.mdx b/developer/sdk.mdx index 0f498cfd..8fbe91a7 100644 --- a/developer/sdk.mdx +++ b/developer/sdk.mdx @@ -1,23 +1,23 @@ --- -title: Using C1's SDKs -og:title: Using C1's SDKs - C1 -sidebarTitle: "C1 SDKs" +title: Using C1.ai's SDKs +og:title: Using C1.ai's SDKs - C1.ai +sidebarTitle: "C1.ai SDKs" --- A software development kit (SDK) is a collection of tools, libraries, and documentation that helps developers create software. SDKs save developers time and effort by providing pre-written code that can be used to build applications and integrations. -C1 offers SDKs to help developers work efficiently with our API. Get started with the SDK in the language of your choice by following the directions below. +C1.ai offers SDKs to help developers work efficiently with our API. Get started with the SDK in the language of your choice by following the directions below. -Are you eager for a C1 SDK in a different language? [Let us know!](mailto:support@c1.ai) +Are you eager for a C1.ai SDK in a different language? [Let us know!](mailto:support@c1.ai) ## Go SDK -Access the [C1 Go SDK](https://github.com/conductorone/conductorone-sdk-go) on GitHub, where you'll find installation instructions, example usage, and a full list of available resources and operations. +Access the [C1.ai Go SDK](https://github.com/conductorone/conductorone-sdk-go) on GitHub, where you'll find installation instructions, example usage, and a full list of available resources and operations. ## Typescript SDK -Access the [C1 Typescript SDK](https://github.com/conductorone/conductorone-sdk-typescript) on GitHub, where you'll find installation instructions, example usage, and a full list of available resources and operations. +Access the [C1.ai Typescript SDK](https://github.com/conductorone/conductorone-sdk-typescript) on GitHub, where you'll find installation instructions, example usage, and a full list of available resources and operations. diff --git a/developer/submit.mdx b/developer/submit.mdx index 441db54b..2c0d486e 100644 --- a/developer/submit.mdx +++ b/developer/submit.mdx @@ -4,10 +4,10 @@ sidebarTitle: "Publishing" description: "Share your connector with the community. Make access management better for everyone." --- -You've built a connector that works. Publishing makes it available to everyone using C1: +You've built a connector that works. Publishing makes it available to everyone using C1.ai: - Other organizations can deploy it - It appears in the Connector Hub -- It becomes eligible for hosted mode (C1 runs it for customers) +- It becomes eligible for hosted mode (C1.ai runs it for customers) - The community can contribute improvements ## Publishing flow @@ -65,8 +65,8 @@ Before building a new connector, check if one already exists. If it does but lac ### New connectors -**Option A: Open source under C1** -- Work with C1 to host in their GitHub org +**Option A: Open source under C1.ai** +- Work with C1.ai to host in their GitHub org - Benefits from existing CI/CD and publishing infrastructure **Option B: Open source under your organization** @@ -146,7 +146,7 @@ make test 1. Use the standard project structure 2. Ensure CI/CD is configured with standard GitHub workflows -3. Contact C1 if you want official hosting: +3. Contact C1.ai if you want official hosting: - Open an issue on [baton-sdk](https://github.com/conductorone/baton-sdk/issues) - Include: target system name, API documentation link, your use case 4. Or publish independently under your organization diff --git a/developer/syncing.mdx b/developer/syncing.mdx index 54347dc8..75447b31 100644 --- a/developer/syncing.mdx +++ b/developer/syncing.mdx @@ -12,7 +12,7 @@ Your connector answers three questions: 2. **What permissions are available?** Entitlements that can be granted 3. **Who has what?** Grants connecting users to permissions -The Baton SDK handles orchestration, output format, pagination coordination, and communication with C1. You focus on translating your system's API into the Resource/Entitlement/Grant model. +The Baton SDK handles orchestration, output format, pagination coordination, and communication with C1.ai. You focus on translating your system's API into the Resource/Entitlement/Grant model. ## Project structure @@ -177,7 +177,7 @@ func (u *userBuilder) ResourceType(ctx context.Context) *v2.ResourceType { } ``` -Traits tell C1 how to interpret the resource. Use `TRAIT_USER` for people, `TRAIT_GROUP` for collections, `TRAIT_ROLE` for permission bundles. +Traits tell C1.ai how to interpret the resource. Use `TRAIT_USER` for people, `TRAIT_GROUP` for collections, `TRAIT_ROLE` for permission bundles. ### List() @@ -224,7 +224,7 @@ if err != nil { r.WithAnnotation(&v2.RawId{Id: user.ID}) ``` -**Why this matters:** C1 uses the `RawId` to: +**Why this matters:** C1.ai uses the `RawId` to: - **Correlate resources across syncs** - Same ID = same resource, not a duplicate - **Track provenance** - Know which connector discovered which resource - **Enable pre-sync patterns** - Support reservation mechanisms that create placeholders before sync @@ -287,7 +287,7 @@ func (g *groupBuilder) Grants(ctx context.Context, resource *v2.Resource, ## Modeling decisions -How you structure resources and entitlements determines what C1 can manage. +How you structure resources and entitlements determines what C1.ai can manage. ### What to sync as a resource? @@ -344,7 +344,7 @@ Your connector is ready when: - **Sync works deterministically** (same inputs produce stable IDs and consistent results across runs) - **Pagination works** (no token loops; handles large datasets) -- **You can run without production C1 credentials** (local testing story exists) +- **You can run without production C1.ai credentials** (local testing story exists) ### Build and test diff --git a/developer/terraform-best-practices.mdx b/developer/terraform-best-practices.mdx index d4d9ccb9..fe6f645a 100644 --- a/developer/terraform-best-practices.mdx +++ b/developer/terraform-best-practices.mdx @@ -1,30 +1,30 @@ --- -title: "C1 Terraform best practices" -og:title: "C1 Terraform best practices - C1" -og:description: "Best practices for using the C1 Terraform provider, including creating groups, entitlements, access profiles, and policies." -description: "Best practices for using the C1 Terraform provider, including creating groups, entitlements, access profiles, and policies." +title: "C1.ai Terraform best practices" +og:title: "C1.ai Terraform best practices - C1.ai" +og:description: "Best practices for using the C1.ai Terraform provider, including creating groups, entitlements, access profiles, and policies." +description: "Best practices for using the C1.ai Terraform provider, including creating groups, entitlements, access profiles, and policies." sidebarTitle: "Terraform best practices" --- {/* Editor Refresh: 2026-04-29 */} -This guide covers best practices for Terraform practitioners managing C1 resources. Each section is self-contained, so you can read them in any order. +This guide covers best practices for Terraform practitioners managing C1.ai resources. Each section is self-contained, so you can read them in any order. -Before you begin, make sure the C1 Terraform provider is installed and configured. See [C1 Terraform provider](/developer/terraform). +Before you begin, make sure the C1.ai Terraform provider is installed and configured. See [C1.ai Terraform provider](/developer/terraform). -## Creating groups in C1 +## Creating groups in C1.ai -Creating a group in C1 requires three resources working together: +Creating a group in C1.ai requires three resources working together: 1. **An app resource** — the group object itself 2. **A custom app entitlement** — defines the "member" role that users can request 3. **An entitlement automation** — evaluates a CEL expression against user attributes and automatically grants or revokes group membership, with no manual access request required -### Example: create a C1 group with dynamic membership +### Example: create a C1.ai group with dynamic membership -The following example creates a group in the C1 application and automatically adds any user whose `department` attribute contains "engineering." +The following example creates a group in the C1.ai application and automatically adds any user whose `department` attribute contains "engineering." ```hcl # Look up the C1 app. You can also store this ID as a local variable @@ -78,24 +78,24 @@ resource "conductorone_app_entitlement_automation" "dynamic_group_expression" { ### Keep in mind -- **Don't create a new resource type.** The resource type for groups already exists in C1. Creating a duplicate will cause a conflict. -- **The C1 app ID is stable within your tenant.** You can look it up once with a data source, or store it as a local variable if you reference it in multiple places. +- **Don't create a new resource type.** The resource type for groups already exists in C1.ai. Creating a duplicate will cause a conflict. +- **The C1.ai app ID is stable within your tenant.** You can look it up once with a data source, or store it as a local variable if you reference it in multiple places. - **Consider wrapping this pattern in a reusable Terraform module.** You'll repeat these same three resources for every group you create. --- ## Custom app entitlements vs app entitlements -There are two Terraform resources for managing entitlements. Choosing the right one depends on whether the entitlement already exists in C1. +There are two Terraform resources for managing entitlements. Choosing the right one depends on whether the entitlement already exists in C1.ai. -- Use `conductorone_custom_app_entitlement` to **create** a new entitlement that does not yet exist in C1 — for virtual entitlements, or when pre-creating an IDP group before a connector sync. +- Use `conductorone_custom_app_entitlement` to **create** a new entitlement that does not yet exist in C1.ai — for virtual entitlements, or when pre-creating an IDP group before a connector sync. - Use `conductorone_app_entitlement` to **configure or update** an entitlement that a connector already manages. This resource is update-only; it cannot create or delete entitlements. ### Creating virtual entitlements Use [conductorone_custom_app_entitlement](https://registry.terraform.io/providers/ConductorOne/conductorone/latest/docs/resources/custom_app_entitlement) when you need to create a virtual entitlement for a permission not yet discovered by a connector. -This resource also supports the `match_baton_id` field, which links the Terraform resource to an external ID (such as an Okta group ID). When the connector syncs, C1 merges the two rather than creating a duplicate. +This resource also supports the `match_baton_id` field, which links the Terraform resource to an external ID (such as an Okta group ID). When the connector syncs, C1.ai merges the two rather than creating a duplicate. ```hcl data "conductorone_app" "okta_app" { @@ -151,12 +151,12 @@ Use [conductorone_app_entitlement](https://registry.terraform.io/providers/Condu This resource is also used to manage the app access entitlement, a static entitlement that exists on every app. -`conductorone_app_entitlement` is update-only. Running `terraform destroy` removes the resource from Terraform state, but the entitlement still exists in C1. To roll back a change, run a subsequent `terraform apply` with the previous configuration values. +`conductorone_app_entitlement` is update-only. Running `terraform destroy` removes the resource from Terraform state, but the entitlement still exists in C1.ai. To roll back a change, run a subsequent `terraform apply` with the previous configuration values. ### Example: configure app access with account provisioning -Use this pattern when you want C1 to provision a new account in the target system when access is granted, rather than assigning an existing account. +Use this pattern when you want C1.ai to provision a new account in the target system when access is granted, rather than assigning an existing account. ```hcl resource "conductorone_app_entitlement" "app_access" { @@ -216,7 +216,7 @@ resource "conductorone_app_entitlement" "test_entitlement_update_multistep" { - **Terraform import is not required.** Reference the entitlement by ID using a data source lookup. - **JSON encoding is required** for `multi_step` provisioning and `account_provision` config blocks. -- **Entitlement owners** are managed with a separate resource, [conductorone_app_entitlement_owner](https://registry.terraform.io/providers/ConductorOne/conductorone/latest/docs/resources/app_entitlement_owner). Owners are always a list of C1 users — the resource accepts `user_ids` only, and setting the list replaces any existing owners for that entitlement. See the example below. +- **Entitlement owners** are managed with a separate resource, [conductorone_app_entitlement_owner](https://registry.terraform.io/providers/ConductorOne/conductorone/latest/docs/resources/app_entitlement_owner). Owners are always a list of C1.ai users — the resource accepts `user_ids` only, and setting the list replaces any existing owners for that entitlement. See the example below. - **App-level owners** are managed with [conductorone_app_owner](https://registry.terraform.io/providers/ConductorOne/conductorone/latest/docs/resources/app_owner), which takes an `app_id` and a `user_ids` list. Setting `user_ids` replaces any existing owners for the app, and changing either field forces the resource to be replaced. ### Example: manage entitlement owners @@ -259,7 +259,7 @@ When looking up users, the [conductorone_user](https://registry.terraform.io/pro ## Creating access profiles -Access profiles group multiple entitlements into a single requestable bundle. The C1 UI calls these "access profiles," but the Terraform provider and API use the term "catalog" — you'll see `catalog_id` as a field name throughout these resources. +Access profiles group multiple entitlements into a single requestable bundle. The C1.ai UI calls these "access profiles," but the Terraform provider and API use the term "catalog" — you'll see `catalog_id` as a field name throughout these resources. A fully configured access profile requires five related resources: @@ -444,7 +444,7 @@ Policies define the approval workflow for access requests — who reviews, in wh ### Always include a baseline rule -Every policy must include a `grant` key with at least one step. Without it, any request that does not match a named rule's condition will fail or get stuck in an undefined state. Terraform does not validate this requirement — C1 enforces it at runtime. +Every policy must include a `grant` key with at least one step. Without it, any request that does not match a named rule's condition will fail or get stuck in an undefined state. Terraform does not validate this requirement — C1.ai enforces it at runtime. The `grant` key is the catch-all baseline rule. It runs for every request that does not match any named rule's condition. In the examples below, it rejects those unmatched requests by default, so only requests satisfying `my_policy_key`'s condition are auto-approved. @@ -518,7 +518,7 @@ resource "conductorone_policy" "auto_approve_policy" { ### Use built-in policies as templates -Terraform does not validate policy structure the same way the C1 UI does. The safest starting point is to generate HCL from an existing, working policy. +Terraform does not validate policy structure the same way the C1.ai UI does. The safest starting point is to generate HCL from an existing, working policy. @@ -558,7 +558,7 @@ Terraform does not validate policy structure the same way the C1 UI does. The sa ## Related resources -- [C1 Terraform provider](/developer/terraform) +- [C1.ai Terraform provider](/developer/terraform) - [CEL expressions](/product/admin/expressions) - [CEL expressions reference](/product/admin/expressions-reference) - [conductorone_policy on the Terraform Registry](https://registry.terraform.io/providers/ConductorOne/conductorone/latest/docs/resources/policy) diff --git a/developer/terraform.mdx b/developer/terraform.mdx index 1b61941e..b1b96481 100644 --- a/developer/terraform.mdx +++ b/developer/terraform.mdx @@ -1,14 +1,14 @@ --- -title: C1 Terraform provider -og:title: C1 Terraform provider - C1 -og:description: C1's Terraform provider lets you define and manage C1 infrastructure in a declarative way. -description: C1's Terraform provider lets you define and manage C1 infrastructure in a declarative way. -sidebarTitle: "C1 Terraform provider" +title: C1.ai Terraform provider +og:title: C1.ai Terraform provider - C1.ai +og:description: C1.ai's Terraform provider lets you define and manage C1.ai infrastructure in a declarative way. +description: C1.ai's Terraform provider lets you define and manage C1.ai infrastructure in a declarative way. +sidebarTitle: "C1.ai Terraform provider" --- Terraform is an open-source infrastructure-as-code (IAC) tool that lets developers define and manage cloud infrastructure using code. Terraform is declarative, which means that you define the desired state of your infrastructure, and Terraform then automatically creates or updates your infrastructure to match the desired state. This can be helpful for creating and managing complex infrastructure deployments. -C1's Terraform provider can help you automate the provisioning, configuration, and management of C1 resources and integrations. The C1 Terraform provider allows you to configure important management objects, including: +C1.ai's Terraform provider can help you automate the provisioning, configuration, and management of C1.ai resources and integrations. The C1.ai Terraform provider allows you to configure important management objects, including: - Policies - Integrations @@ -25,29 +25,29 @@ The Terraform provider supports three authentication methods: For details on setting up service principals and choosing an authentication method, see [service principals](/product/admin/service-principals/overview). -## Getting started with C1's Terraform provider +## Getting started with C1.ai's Terraform provider -Find [C1's Terraform provider](https://registry.terraform.io/providers/ConductorOne/conductorone/latest) on the Terraform registry. +Find [C1.ai's Terraform provider](https://registry.terraform.io/providers/ConductorOne/conductorone/latest) on the Terraform registry. -C1 Terraform provider on the Terraform registry +C1.ai Terraform provider on the Terraform registry Click **Documentation** on the registry homepage to see the full list of resources and data sources available in the provider. -To get started, click **Use Provider** and follow the instructions provided to add C1's Terraform provider to your Terraform configuration file. +To get started, click **Use Provider** and follow the instructions provided to add C1.ai's Terraform provider to your Terraform configuration file. ## Specialized Terraform capabilities -C1 has built some specialized capabilities in Terraform to address use cases unique to this manner of setting up and using our product. These capabilities do not have equivalents in the web UI. +C1.ai has built some specialized capabilities in Terraform to address use cases unique to this manner of setting up and using our product. These capabilities do not have equivalents in the web UI. -### Merge an IdP group with a C1 group +### Merge an IdP group with a C1.ai group -Traditionally, creating a group in an IdP and then configuring its properties in C1 required a multi-step, manual process. You'd have to run Terraform against the IdP, wait for C1 to sync the new group, and then run a separate Terraform script against C1 after manually matching the group names. This was inefficient and prone to errors. +Traditionally, creating a group in an IdP and then configuring its properties in C1.ai required a multi-step, manual process. You'd have to run Terraform against the IdP, wait for C1.ai to sync the new group, and then run a separate Terraform script against C1.ai after manually matching the group names. This was inefficient and prone to errors. -Now, with the Group ID as a join key, you can perform a single Terraform run that creates a group in C1 and simultaneously merges that group with the corresponding IdP group. This eliminates the need to wait for multiple C1 syncs and dramatically simplifies your group management process. +Now, with the Group ID as a join key, you can perform a single Terraform run that creates a group in C1.ai and simultaneously merges that group with the corresponding IdP group. This eliminates the need to wait for multiple C1.ai syncs and dramatically simplifies your group management process. -Here are sample Terraform files demonstrating how to use the `match_baton_id` key to sync a C1 group with Okta: +Here are sample Terraform files demonstrating how to use the `match_baton_id` key to sync a C1.ai group with Okta: **okta.tf file:** diff --git a/docs.json b/docs.json index da3b3a1f..6ff8c60b 100644 --- a/docs.json +++ b/docs.json @@ -45,12 +45,12 @@ "href": "/", "light": "/logo/dark.svg" }, - "name": "C1 documentation", + "name": "C1.ai documentation", "navbar": { "links": [ { "href": "https://accounts.conductor.one/accounts", - "label": "Sign into C1" + "label": "Sign into C1.ai" } ], "primary": { @@ -88,7 +88,7 @@ ] } ], - "tab": "Use C1" + "tab": "Use C1.ai" }, { "icon": "gear", @@ -404,7 +404,7 @@ ] }, { - "group": "C1 CLIs", + "group": "C1.ai CLIs", "pages": [ { "group": "Cone (for humans)", @@ -427,7 +427,7 @@ ] } ], - "tab": "Administer C1" + "tab": "Administer C1.ai" }, { "icon": "code-merge", @@ -928,7 +928,7 @@ ] }, { - "group": "C1 developer tools", + "group": "C1.ai developer tools", "pages": [ "developer/sdk", "developer/postman", diff --git a/index.mdx b/index.mdx index bb34570e..1585bf36 100644 --- a/index.mdx +++ b/index.mdx @@ -1,5 +1,5 @@ --- -title: "C1 documentation" +title: "C1.ai documentation" mode: "custom" ---
@@ -7,10 +7,10 @@ mode: "custom"

- C1 docs + C1.ai docs

- Everything you need to configure, extend, and get the most out of C1. + Everything you need to configure, extend, and get the most out of C1.ai.

@@ -58,10 +58,10 @@ mode: "custom"

- Use C1 + Use C1.ai

- Request access, complete review tasks, and use AI tools and MCP clients as an end user of C1. + Request access, complete review tasks, and use AI tools and MCP clients as an end user of C1.ai.

Learn more @@ -77,7 +77,7 @@ mode: "custom"

- Administer C1 + Administer C1.ai

Automate security for all your human, non-human, and AI identities. Run access reviews, enable self-service access, and set up just-in-time access for key resources. @@ -122,7 +122,7 @@ mode: "custom" Developer

- Work with our Go and TypeScript SDKs, Terraform provider, and Postman integration. Integrate with, manage, and extend the C1 platform programmatically. + Work with our Go and TypeScript SDKs, Terraform provider, and Postman integration. Integrate with, manage, and extend the C1.ai platform programmatically.

Learn more @@ -144,7 +144,7 @@ mode: "custom" API

- Extend C1's power into your own ecosystem. Automate access requests, export audit data for compliance reporting, and integrate identity security directly into your internal tools and developer workflows. + Extend C1.ai's power into your own ecosystem. Automate access requests, export audit data for compliance reporting, and integrate identity security directly into your internal tools and developer workflows.

Learn more diff --git a/rap/INDEX.md b/rap/INDEX.md index 7de79fc0..dad5ce27 100644 --- a/rap/INDEX.md +++ b/rap/INDEX.md @@ -1,4 +1,4 @@ -# C1 RAP Documentation +# C1.ai RAP Documentation Retrieval Augmented Prompt (RAP) documentation for AI agents. Each subdirectory contains focused, self-contained documentation chunks optimized for selective retrieval. @@ -17,7 +17,7 @@ Retrieval Augmented Prompt (RAP) documentation for AI agents. Each subdirectory | **Connectors** | `connectors/INDEX.md` | Building Baton connectors, sync/provision patterns, SDK interfaces | | **Service Principals** | `service-principals/INDEX.md` | API automation, client credentials, workload federation, CI/CD integration | | **CEL Expressions** | `cel-expressions/index.md` | Writing CEL in policies, dynamic groups, automations, access reviews | -| **MCP Gateway** | `mcp-gateway/INDEX.md` | Interacting with C1's MCP gateway and code mode as an AI agent | +| **MCP Gateway** | `mcp-gateway/INDEX.md` | Interacting with C1.ai's MCP gateway and code mode as an AI agent | ## Quick Routing Guide @@ -30,7 +30,7 @@ Retrieval Augmented Prompt (RAP) documentation for AI agents. Each subdirectory **User asks about expressions, policies, dynamic groups, automation conditions:** → `cel-expressions/index.md` -**User's agent is connected to C1's MCP endpoint, or asks about code mode, `execute`, `describe`, tool access denials, access-request envelopes:** +**User's agent is connected to C1.ai's MCP endpoint, or asks about code mode, `execute`, `describe`, tool access denials, access-request envelopes:** → `mcp-gateway/INDEX.md` ## Subdirectory Structure diff --git a/rap/cel-expressions/env-account-provisioning.md b/rap/cel-expressions/env-account-provisioning.md index 739db723..31aee1d7 100644 --- a/rap/cel-expressions/env-account-provisioning.md +++ b/rap/cel-expressions/env-account-provisioning.md @@ -109,7 +109,7 @@ c1.user.v1.GetAppUsersForUser(subject, "app-id") | Scenario | What Happens | How to Handle | |----------|--------------|---------------| | Profile attribute missing | Empty string or error | Use `has()` check | -| Attribute mapping not found | Empty value | Check mapping exists in C1 config | +| Attribute mapping not found | Empty value | Check mapping exists in C1.ai config | | `entitlement` not available | Compile error if referenced | Check context provides entitlement | | `task` not available | Compile error if referenced | Check context provides task | diff --git a/rap/cel-expressions/env-workflow.md b/rap/cel-expressions/env-workflow.md index 95834d6b..f5a180b9 100644 --- a/rap/cel-expressions/env-workflow.md +++ b/rap/cel-expressions/env-workflow.md @@ -1,6 +1,6 @@ # Workflow Execution Expressions -Dynamic data access within C1 workflow automations. Supports template interpolation and step-to-step data flow. +Dynamic data access within C1.ai workflow automations. Supports template interpolation and step-to-step data flow. ## When to Use diff --git a/rap/cel-expressions/functions-strings.md b/rap/cel-expressions/functions-strings.md index 27f3fbaa..fe91936b 100644 --- a/rap/cel-expressions/functions-strings.md +++ b/rap/cel-expressions/functions-strings.md @@ -1,10 +1,10 @@ # String Functions -Standard CEL string methods plus C1 extensions. +Standard CEL string methods plus C1.ai extensions. ## ifEmpty() -Return a default value if string is empty. C1 extension. +Return a default value if string is empty. C1.ai extension. ```cel string.ifEmpty(default: string) -> string diff --git a/rap/cel-expressions/index.md b/rap/cel-expressions/index.md index 6dae5b11..38aff612 100644 --- a/rap/cel-expressions/index.md +++ b/rap/cel-expressions/index.md @@ -1,10 +1,10 @@ # CEL Expression Knowledge Base -This directory contains focused documentation chunks for CEL (Common Expression Language) in C1. Each file is self-contained and designed for selective retrieval. +This directory contains focused documentation chunks for CEL (Common Expression Language) in C1.ai. Each file is self-contained and designed for selective retrieval. ## How to Use This Index -When answering questions about CEL expressions in C1: +When answering questions about CEL expressions in C1.ai: 1. Identify the question type from the tables below 2. Retrieve 1-3 relevant files from this directory diff --git a/rap/cel-expressions/overview-intro.md b/rap/cel-expressions/overview-intro.md index 45265fd4..032eb12e 100644 --- a/rap/cel-expressions/overview-intro.md +++ b/rap/cel-expressions/overview-intro.md @@ -1,6 +1,6 @@ # CEL Overview -CEL (Common Expression Language) is Google's expression language for policy evaluation. C1 uses CEL to let you encode access logic that would be impossible with dropdown menus. +CEL (Common Expression Language) is Google's expression language for policy evaluation. C1.ai uses CEL to let you encode access logic that would be impossible with dropdown menus. ## Why CEL for Authorization @@ -37,15 +37,15 @@ c1.directory.users.v1.GetManagers(subject) size(managers) > 0 ? managers : appOwners ``` -## What's C1's vs Google's +## What's C1.ai's vs Google's -| Layer | Google's CEL | C1's Extensions | +| Layer | Google's CEL | C1.ai's Extensions | |-------|--------------|---------------------------| | Syntax | All operators, macros (`has()`, `size()`) | Nothing added | | Types | Primitives, lists, maps, timestamps | `User`, `Task`, `AppEntitlement` | | Functions | String methods, math | `c1.directory.*`, `c1.user.*` | -**Rule of thumb:** If it starts with `c1.`, it's C1's extension. +**Rule of thumb:** If it starts with `c1.`, it's C1.ai's extension. ## How Expressions are Evaluated diff --git a/rap/cel-expressions/terraform-examples.md b/rap/cel-expressions/terraform-examples.md index 9b62a54a..ad274cba 100644 --- a/rap/cel-expressions/terraform-examples.md +++ b/rap/cel-expressions/terraform-examples.md @@ -1,6 +1,6 @@ # CEL in Terraform -CEL expressions in the C1 Terraform provider. +CEL expressions in the C1.ai Terraform provider. ## Resources Supporting CEL @@ -155,6 +155,6 @@ EOT ## Tips -1. **Validate in UI first** - Test expressions in the C1 UI before deploying via Terraform +1. **Validate in UI first** - Test expressions in the C1.ai UI before deploying via Terraform 2. **Use heredoc for readability** - Complex expressions are easier to read with heredoc syntax 3. **Check return types** - Conditions return `bool`, approvers return `User`/`list` diff --git a/rap/cel-expressions/types.md b/rap/cel-expressions/types.md index a0fd2e0c..594fc5fa 100644 --- a/rap/cel-expressions/types.md +++ b/rap/cel-expressions/types.md @@ -1,6 +1,6 @@ # CEL Type Definitions -This document covers all types used in C1 CEL expressions: primitives, time types, collections, enums, and object types. +This document covers all types used in C1.ai CEL expressions: primitives, time types, collections, enums, and object types. ## Primitive Types @@ -74,7 +74,7 @@ Always use the full enum name (e.g., `UserStatus.ENABLED`, not just `ENABLED`). | Value | Meaning | |:------|:--------| -| `TaskOrigin.WEBAPP` | Created in C1 web interface | +| `TaskOrigin.WEBAPP` | Created in C1.ai web interface | | `TaskOrigin.SLACK` | Created via Slack integration | | `TaskOrigin.API` | Created via API | | `TaskOrigin.JIRA` | Created via Jira integration | @@ -106,14 +106,14 @@ Used in `ctx.trigger.oldAccount.status.status` and `ctx.trigger.newAccount.statu ### User vs AppUser These are different types: -- **User** = A person in the C1 directory (synced from identity provider) +- **User** = A person in the C1.ai directory (synced from identity provider) - **AppUser** = That person's account in a specific app (GitHub account, Okta account, etc.) One User can have many AppUsers across different connected applications. ### User -A person in the C1 directory. +A person in the C1.ai directory. **Returned by:** `FindByEmail`, `GetByID`, `GetManagers`, `DirectReports`, `GetEntitlementMembers` @@ -164,7 +164,7 @@ A user's account within a specific connected application. ### Group -A C1 group (entitlement in the builtin Groups app). +A C1.ai group (entitlement in the builtin Groups app). **Returned by:** `FindByName` diff --git a/rap/connectors/INDEX.md b/rap/connectors/INDEX.md index a5f616c4..b11ad6f1 100644 --- a/rap/connectors/INDEX.md +++ b/rap/connectors/INDEX.md @@ -1,6 +1,6 @@ # Baton Connector Documentation Index -Documentation for building C1 Baton connectors. Request relevant sections based on user's question. +Documentation for building C1.ai Baton connectors. Request relevant sections based on user's question. ## How to Use @@ -72,7 +72,7 @@ Documentation for building C1 Baton connectors. Request relevant sections based |---------|------|--------| | SDK interfaces | `ref-sdk.md` | ConnectorBuilder, ResourceSyncer, Provisioner | | Configuration | `ref-config.md` | Flags, env vars, field types | -| C1 API | `ref-c1api.md` | Task types, lifecycle, heartbeat | +| C1.ai API | `ref-c1api.md` | Task types, lifecycle, heartbeat | | FAQ | `ref-faq.md` | Common questions | | Glossary | `ref-glossary.md` | Term definitions | @@ -128,7 +128,7 @@ Documentation for building C1 Baton connectors. Request relevant sections based **Architecture** - SDK interfaces -> `ref-sdk.md` -- C1 communication -> `ref-c1api.md` +- C1.ai communication -> `ref-c1api.md` --- diff --git a/rap/connectors/community.md b/rap/connectors/community.md index a117479c..66ebfde5 100644 --- a/rap/connectors/community.md +++ b/rap/connectors/community.md @@ -39,7 +39,7 @@ Good: "Sync fails with 'unauthorized' when listing users. Using baton-okta v0.5. |---------|----------|---------| | GitHub Issues | Days | Bugs, features | | GitHub Discussions | Days | Questions | -| C1 Support | Hours | Production (customers) | +| C1.ai Support | Hours | Production (customers) | --- diff --git a/rap/connectors/concepts-ids.md b/rap/connectors/concepts-ids.md index c6169bd3..54cdcd82 100644 --- a/rap/connectors/concepts-ids.md +++ b/rap/connectors/concepts-ids.md @@ -1,12 +1,12 @@ # concepts-ids -RawId annotation, external_id, and how C1 matches resources across syncs. +RawId annotation, external_id, and how C1.ai matches resources across syncs. --- ## Why ID Correlation Matters -C1 needs to know if a resource in this sync is the same resource from a previous sync. This enables: +C1.ai needs to know if a resource in this sync is the same resource from a previous sync. This enables: - Tracking changes over time - Correlating resources across connectors - Supporting pre-sync reservation patterns @@ -60,8 +60,8 @@ Use the external system's native, stable identifier: **Using composite keys:** If you construct `org/repo`, changes to either part break correlation. -**Omitting RawId:** Without it, C1 can't correlate resources across syncs. +**Omitting RawId:** Without it, C1.ai can't correlate resources across syncs. ## Pre-sync Reservation -The `match_baton_id` field (in Terraform/API) allows creating C1 objects before the connector discovers them. When the connector syncs, resources are matched by this ID. +The `match_baton_id` field (in Terraform/API) allows creating C1.ai objects before the connector discovers them. When the connector syncs, resources are matched by this ID. diff --git a/rap/connectors/concepts-overview.md b/rap/connectors/concepts-overview.md index ba6da3c4..97b7a0f1 100644 --- a/rap/connectors/concepts-overview.md +++ b/rap/connectors/concepts-overview.md @@ -8,7 +8,7 @@ What connectors do, sync vs provision, the reconciliation loop. A **connector** answers: *who has access to what?* -C1 needs visibility into users, groups, roles, and permissions across all systems. Every system stores this differently - Okta has users and groups, AWS has IAM roles and policies, Salesforce has profiles and permission sets. +C1.ai needs visibility into users, groups, roles, and permissions across all systems. Every system stores this differently - Okta has users and groups, AWS has IAM roles and policies, Salesforce has profiles and permission sets. A connector translates access data from any system into a common format. Once connected, you get unified visibility across your infrastructure. @@ -21,7 +21,7 @@ In Baton terms, a connector is a program that can: ## Sync vs Provision -**Sync** (read): Pull access data into C1 +**Sync** (read): Pull access data into C1.ai - Who exists? What groups? What roles? - What permissions are available? - Who has what access right now? @@ -36,7 +36,7 @@ In Baton terms, a connector is a program that can: Together, sync and provision create a reconciliation loop: -1. C1 sees what access exists (sync) +1. C1.ai sees what access exists (sync) 2. Compares to what access *should* exist (policy) 3. Corrects any drift (provision) diff --git a/rap/connectors/concepts-resources.md b/rap/connectors/concepts-resources.md index 1fa00406..9b238f63 100644 --- a/rap/connectors/concepts-resources.md +++ b/rap/connectors/concepts-resources.md @@ -35,7 +35,7 @@ Each resource has a **resource type** with optional **traits**. ## Traits -Traits tell C1 how to interpret a resource: +Traits tell C1.ai how to interpret a resource: | Trait | Use For | |-------|---------| diff --git a/rap/connectors/concepts-sync.md b/rap/connectors/concepts-sync.md index d141d3bc..7e31cfdd 100644 --- a/rap/connectors/concepts-sync.md +++ b/rap/connectors/concepts-sync.md @@ -77,8 +77,8 @@ flowchart LR 1. **Fetch** - Your connector calls external API 2. **Transform** - Create Resource/Entitlement/Grant objects 3. **Output** - SDK writes to .c1z file (gzip SQLite) -4. **Ingest** - C1 reads the file +4. **Ingest** - C1.ai reads the file 5. **Uplift** - Raw records become domain objects **You control:** Steps 1-3 -**C1 controls:** Steps 4-5 +**C1.ai controls:** Steps 4-5 diff --git a/rap/connectors/ops-modes.md b/rap/connectors/ops-modes.md index a5c3a10c..fca7c4f8 100644 --- a/rap/connectors/ops-modes.md +++ b/rap/connectors/ops-modes.md @@ -9,8 +9,8 @@ One-shot vs daemon vs hosted mode. | Mode | Trigger | Behavior | |------|---------|----------| | **One-shot** | No `--client-id` | Run once, produce .c1z file, exit | -| **Daemon** | `--client-id` provided | Connect to C1, poll for tasks, run continuously | -| **Hosted** | C1 infrastructure | Managed by C1, no local deployment | +| **Daemon** | `--client-id` provided | Connect to C1.ai, poll for tasks, run continuously | +| **Hosted** | C1.ai infrastructure | Managed by C1.ai, no local deployment | ## One-Shot Mode @@ -34,7 +34,7 @@ Use for: ## Daemon Mode -Connect to C1 and process tasks continuously: +Connect to C1.ai and process tasks continuously: ```bash ./baton-myservice \ @@ -44,7 +44,7 @@ Connect to C1 and process tasks continuously: ``` The connector: -1. Authenticates to C1 +1. Authenticates to C1.ai 2. Polls for sync/provisioning tasks 3. Executes tasks and reports results 4. Repeats until stopped @@ -56,12 +56,12 @@ Use for: ## Hosted Mode -C1 runs the connector for you: +C1.ai runs the connector for you: - No infrastructure to manage - Automatic updates -- Credentials stored in C1 +- Credentials stored in C1.ai -Check if your connector is available as hosted in the C1 console. +Check if your connector is available as hosted in the C1.ai console. ## Provisioning Flag diff --git a/rap/connectors/ref-c1api.md b/rap/connectors/ref-c1api.md index 10c1ebfb..1d021198 100644 --- a/rap/connectors/ref-c1api.md +++ b/rap/connectors/ref-c1api.md @@ -1,6 +1,6 @@ # ref-c1api -How connectors communicate with C1 platform. SDK handles this; understanding helps debugging. +How connectors communicate with C1.ai platform. SDK handles this; understanding helps debugging. --- @@ -50,7 +50,7 @@ type SyncTask struct { } ``` -Produces: c1z file uploaded to C1 +Produces: c1z file uploaded to C1.ai ### GrantTask diff --git a/rap/connectors/ref-config.md b/rap/connectors/ref-config.md index 6c6aa839..d8991e99 100644 --- a/rap/connectors/ref-config.md +++ b/rap/connectors/ref-config.md @@ -28,8 +28,8 @@ CLI wins over env, env wins over file. | Flag | Description | |------|-------------| -| `--client-id` | C1 OAuth client ID (enables daemon mode) | -| `--client-secret` | C1 OAuth client secret | +| `--client-id` | C1.ai OAuth client ID (enables daemon mode) | +| `--client-secret` | C1.ai OAuth client secret | | `--skip-full-sync` | Disable full sync in daemon mode | ### Provisioning diff --git a/rap/connectors/ref-faq.md b/rap/connectors/ref-faq.md index 8e3fbf2b..0176020b 100644 --- a/rap/connectors/ref-faq.md +++ b/rap/connectors/ref-faq.md @@ -11,8 +11,8 @@ Common questions about baton connectors. | Tool | Purpose | User | |------|---------|------| | baton-sdk | Go SDK for building connectors | Connector developers | -| cone | CLI for C1 platform ops | End users (requests, approvals) | -| conductorone-sdk-go | Go SDK for C1 API | App integrators | +| cone | CLI for C1.ai platform ops | End users (requests, approvals) | +| conductorone-sdk-go | Go SDK for C1.ai API | App integrators | Building a connector? Use baton-sdk. diff --git a/rap/connectors/ref-glossary.md b/rap/connectors/ref-glossary.md index 1c465c27..6db4bc3d 100644 --- a/rap/connectors/ref-glossary.md +++ b/rap/connectors/ref-glossary.md @@ -40,7 +40,7 @@ Term definitions for Baton connector development. | Term | Definition | |------|------------| | **Sync** | Reading access data from a system | -| **Uplift** | C1 process transforming raw records to domain objects | +| **Uplift** | C1.ai process transforming raw records to domain objects | | **ID Correlation** | Matching resources across syncs using RawId | ## Provisioning @@ -58,8 +58,8 @@ Term definitions for Baton connector development. | Term | Definition | |------|------------| | **One-shot** | Run once, produce c1z file, exit | -| **Daemon** | Long-running, polls C1 for tasks | -| **Hosted** | Run by C1 infrastructure | +| **Daemon** | Long-running, polls C1.ai for tasks | +| **Hosted** | Run by C1.ai infrastructure | ## Meta-Connector Terms diff --git a/rap/mcp-gateway/INDEX.md b/rap/mcp-gateway/INDEX.md index 3e99950d..77d3583e 100644 --- a/rap/mcp-gateway/INDEX.md +++ b/rap/mcp-gateway/INDEX.md @@ -1,8 +1,8 @@ # MCP Gateway Documentation Index -Documentation for interacting with ConductorOne (C1) as an MCP gateway, and for the code-mode interface agents use to call governed tools through it. Request relevant sections based on the user's question. +Documentation for interacting with ConductorOne (C1.ai) as an MCP gateway, and for the code-mode interface agents use to call governed tools through it. Request relevant sections based on the user's question. -C1 is an MCP gateway: an AI client connects to one C1 MCP endpoint, and C1 sits in front of the organization's approved MCP servers. Agents do not connect to those upstream servers directly. Every call is identity-aware, governed per tool, and audit logged. +C1.ai is an MCP gateway: an AI client connects to one C1.ai MCP endpoint, and C1.ai sits in front of the organization's approved MCP servers. Agents do not connect to those upstream servers directly. Every call is identity-aware, governed per tool, and audit logged. ## How to Use @@ -25,7 +25,7 @@ C1 is an MCP gateway: an AI client connects to one C1 MCP endpoint, and C1 sits ## Selection Guidelines **"What is..."** -- C1 MCP / the C1 gateway / C1 MCP URL -> `concepts-gateway.md` +- C1.ai MCP / the C1.ai gateway / C1.ai MCP URL -> `concepts-gateway.md` - Code mode -> `concepts-gateway.md`, `use-code-mode.md` - `describe` / `execute` -> `use-code-mode.md` - `get_execution` -> `use-async-executions.md` @@ -57,7 +57,7 @@ C1 is an MCP gateway: an AI client connects to one C1 MCP endpoint, and C1 sits **Governance questions** - Why a call was blocked -> `concepts-gateway.md`, `use-access-requests.md` -- What C1 logs per call -> `concepts-gateway.md` +- What C1.ai logs per call -> `concepts-gateway.md` - Which client types get code mode -> `concepts-gateway.md` --- @@ -76,7 +76,7 @@ Retrieve: `use-access-requests.md` User: "execute came back pending with an execution_id" Retrieve: `use-async-executions.md` -User: "How does C1 decide whether my agent can call a tool?" +User: "How does C1.ai decide whether my agent can call a tool?" Retrieve: `concepts-gateway.md` User: "The result came back with the salary field redacted" diff --git a/rap/mcp-gateway/concepts-gateway.md b/rap/mcp-gateway/concepts-gateway.md index c3431fe5..e6dfe40c 100644 --- a/rap/mcp-gateway/concepts-gateway.md +++ b/rap/mcp-gateway/concepts-gateway.md @@ -1,15 +1,15 @@ -# C1 as an MCP Gateway +# C1.ai as an MCP Gateway -ConductorOne (C1) is an MCP gateway. An AI client connects to one C1 MCP endpoint, and C1 sits in front of the organization's approved MCP servers and integrations. Agents do not connect to those upstream servers directly. +ConductorOne (C1.ai) is an MCP gateway. An AI client connects to one C1.ai MCP endpoint, and C1.ai sits in front of the organization's approved MCP servers and integrations. Agents do not connect to those upstream servers directly. Mental model: **one MCP connection, many governed systems behind it.** ## What the Gateway Does on Every Call -1. **Authenticates the caller.** C1 resolves the human or workload identity behind the agent. Every tool call carries that identity — the gateway is identity-aware, not an anonymous relay. +1. **Authenticates the caller.** C1.ai resolves the human or workload identity behind the agent. Every tool call carries that identity — the gateway is identity-aware, not an anonymous relay. 2. **Checks governance.** The tool must be **Enabled** by an admin, and the caller must hold a **grant** for it. Both conditions are required. Enabling a tool does not grant it to anyone. 3. **Runs hooks.** Admin-configured pre-tool-use hooks may rewrite the input or deny the call. -4. **Routes upstream.** C1 forwards the call to the correct upstream server using that server's configured auth mode, so the agent never handles upstream credentials. +4. **Routes upstream.** C1.ai forwards the call to the correct upstream server using that server's configured auth mode, so the agent never handles upstream credentials. 5. **Runs post hooks.** Post-tool-use hooks may rewrite, redact, or deny the returned output. 6. **Writes an audit log entry** with identity, client, server, tool, result, denial reason, and latency. @@ -19,17 +19,17 @@ The agent cannot tell these apart and does not need to. All appear as tools behi | Upstream | What it is | |----------|------------| -| Hosted catalog server | An MCP server C1 hosts and registers on the org's behalf | +| Hosted catalog server | An MCP server C1.ai hosts and registers on the org's behalf | | Vendor MCP server | A third-party MCP server registered by an admin | -| Bridged server | A private or on-premises MCP server reached through C1's MCP bridge | +| Bridged server | A private or on-premises MCP server reached through C1.ai's MCP bridge | ## Toolsets, Access Profiles, and Grants - A **tool** is one capability exposed by an upstream MCP server (for example, `github_create_issue`). - Discovered tools start in an unreviewed state. An admin approves/enables them and may classify them by action (read / write / delete) and risk. -- Approved tools are bundled into a **toolset** — either C1-maintained ("All approved", "Read-only") or an admin-curated custom toolset. +- Approved tools are bundled into a **toolset** — either C1.ai-maintained ("All approved", "Read-only") or an admin-curated custom toolset. - A toolset is bound to an **access profile**, which carries the approval policy, approvers, and expiry. -- A user requests the access profile from the C1 catalog (web, Slack, or from their AI client). Once approved, the grant makes the toolset's tools callable by that user's clients. +- A user requests the access profile from the C1.ai catalog (web, Slack, or from their AI client). Once approved, the grant makes the toolset's tools callable by that user's clients. Consequence for agents: the tool surface is per-caller, not per-tenant. Two agents connected to the same gateway can see and call different sets of tools. @@ -71,7 +71,7 @@ Governance is identical in both shapes. Code mode changes the calling interface, When the caller lacks access to a tool, the gateway does not fail with a generic error. It returns a structured envelope: -- `{status: 'request_created', tool, task_id, task_number, task_url, entitlement_id}` — the tool is requestable. C1 opened an access request; the upstream API was **not** called. Once the request is approved, the same call executes. +- `{status: 'request_created', tool, task_id, task_number, task_url, entitlement_id}` — the tool is requestable. C1.ai opened an access request; the upstream API was **not** called. Once the request is approved, the same call executes. - `{status: 'denied', reason}` — no access path exists for this caller. This is the gateway's signature behavior and the thing agents most often misread. A `request_created` result is not a failure and not an empty result set — it means a request was filed and the human needs the task link. @@ -80,7 +80,7 @@ Correct agent behavior: check for these envelopes before touching any domain fie ## Two Governance Paths, One Platform -C1 governs MCP access two ways. The gateway path (this document) proxies the agent's tool calls through C1. In **enterprise-managed authorization**, C1 instead issues a short-lived scoped token and the agent calls the MCP server directly. Code mode, `describe`/`execute`, and access-request envelopes belong to the gateway path only. +C1.ai governs MCP access two ways. The gateway path (this document) proxies the agent's tool calls through C1.ai. In **enterprise-managed authorization**, C1.ai instead issues a short-lived scoped token and the agent calls the MCP server directly. Code mode, `describe`/`execute`, and access-request envelopes belong to the gateway path only. ## Also in This Domain diff --git a/rap/mcp-gateway/use-access-requests.md b/rap/mcp-gateway/use-access-requests.md index 48708439..e874a08c 100644 --- a/rap/mcp-gateway/use-access-requests.md +++ b/rap/mcp-gateway/use-access-requests.md @@ -1,6 +1,6 @@ # Handling Access-Request Envelopes -ConductorOne (C1) is an MCP gateway: one MCP endpoint in front of the organization's approved MCP servers, enforcing governance on every call. A tool call only executes when the tool is **Enabled** by an admin and the caller holds a **grant** for it. When the caller lacks access, the gateway does not fail opaquely — it returns a structured envelope in place of domain data. +ConductorOne (C1.ai) is an MCP gateway: one MCP endpoint in front of the organization's approved MCP servers, enforcing governance on every call. A tool call only executes when the tool is **Enabled** by an admin and the caller holds a **grant** for it. When the caller lacks access, the gateway does not fail opaquely — it returns a structured envelope in place of domain data. This applies to any `tools.()` call inside an `execute` program, and to directly named tool calls where code mode is off. @@ -19,7 +19,7 @@ This applies to any `tools.()` call inside an `execute` program, and t } ``` -Meaning: the tool is *requestable* by this caller but not yet granted. C1 opened an access request on the caller's behalf. **The upstream API was not called** — no data was read, nothing was written. Approval flows through the tool's normal policy (manager approval, auto-approve, JIT expiry, and so on). Once the grant lands, the same call executes normally. +Meaning: the tool is *requestable* by this caller but not yet granted. C1.ai opened an access request on the caller's behalf. **The upstream API was not called** — no data was read, nothing was written. Approval flows through the tool's normal policy (manager approval, auto-approve, JIT expiry, and so on). Once the grant lands, the same call executes normally. **No access path:** @@ -80,7 +80,7 @@ if (blocked) return blocked; ## Agent Behavior After `request_created` 1. Stop that line of work. Do not proceed with dependent steps that need the missing data. -2. Give the user the `task_url` directly, plus which tool it is for. The user (or an approver) acts on it in C1. +2. Give the user the `task_url` directly, plus which tool it is for. The user (or an approver) acts on it in C1.ai. 3. Report what remains blocked so the user knows what will resume. 4. Retry only after the user confirms approval. Retrying before approval returns the same envelope, and may re-surface the same pending task. 5. If part of the task is independently answerable with tools that did succeed, complete that part and state clearly what is still blocked. @@ -102,15 +102,15 @@ In both cases, report what happened and stop. Do not retry with the same input, ## How a Caller Gets Access -Tool access is granted through C1's normal request-and-approval flow. Approved tools are bundled into **toolsets**, toolsets are bound to **access profiles**, and a user requests the access profile: +Tool access is granted through C1.ai's normal request-and-approval flow. Approved tools are bundled into **toolsets**, toolsets are bound to **access profiles**, and a user requests the access profile: -1. In C1, go to **Requests**. Access profiles containing toolsets appear in the catalog next to app entitlements, each showing which toolset it grants, which tools are in it, and the approval policy (auto-approve, requires approval, or JIT with an expiry). +1. In C1.ai, go to **Requests**. Access profiles containing toolsets appear in the catalog next to app entitlements, each showing which toolset it grants, which tools are in it, and the approval policy (auto-approve, requires approval, or JIT with an expiry). 2. Open the access profile and click **Request access**, adding a justification if required. -3. Alternatively submit from Slack with `/c1 request` where the C1 Slack integration is installed. The same approval flow runs either way. +3. Alternatively submit from Slack with `/c1 request` where the C1.ai Slack integration is installed. The same approval flow runs either way. 4. Track status on **My requests**; notifications arrive by Slack or email depending on tenant configuration. A `request_created` envelope has already filed this request — the user follows the `task_url` rather than starting a new one. -Once approved, the granted tools become callable from the user's AI client, usually after the connection refreshes. Some upstream services also require the user's own credentials (per-user OAuth); the user authorizes those from their C1 profile under **AI & API > MCP connections**. +Once approved, the granted tools become callable from the user's AI client, usually after the connection refreshes. Some upstream services also require the user's own credentials (per-user OAuth); the user authorizes those from their C1.ai profile under **AI & API > MCP connections**. Access can also disappear mid-session: a revoked grant, an expired JIT grant, a flipped kill switch, or a client closed for inactivity all cause subsequent calls to return a denial. In-flight calls finish. diff --git a/rap/mcp-gateway/use-async-executions.md b/rap/mcp-gateway/use-async-executions.md index 4644c847..0ce3a881 100644 --- a/rap/mcp-gateway/use-async-executions.md +++ b/rap/mcp-gateway/use-async-executions.md @@ -1,6 +1,6 @@ # Async Executions and Polling -ConductorOne (C1) is an MCP gateway: one MCP endpoint in front of the organization's approved MCP servers. In code mode, the agent runs work by passing a TypeScript program to `execute`. A program that runs longer than the synchronous wait window does not fail — it continues server-side and is collected by polling. +ConductorOne (C1.ai) is an MCP gateway: one MCP endpoint in front of the organization's approved MCP servers. In code mode, the agent runs work by passing a TypeScript program to `execute`. A program that runs longer than the synchronous wait window does not fail — it continues server-side and is collected by polling. ## The Contract diff --git a/rap/mcp-gateway/use-code-mode.md b/rap/mcp-gateway/use-code-mode.md index 66b4c223..21789e2c 100644 --- a/rap/mcp-gateway/use-code-mode.md +++ b/rap/mcp-gateway/use-code-mode.md @@ -1,6 +1,6 @@ # Using Code Mode -ConductorOne (C1) is an MCP gateway: one MCP endpoint in front of the organization's approved MCP servers. In **code mode**, the gateway does not list each upstream tool as its own named tool. It exposes two entrypoints, and the agent invokes upstream tools by writing a short TypeScript program. +ConductorOne (C1.ai) is an MCP gateway: one MCP endpoint in front of the organization's approved MCP servers. In **code mode**, the gateway does not list each upstream tool as its own named tool. It exposes two entrypoints, and the agent invokes upstream tools by writing a short TypeScript program. | Entrypoint | Purpose | |------------|---------| diff --git a/rap/service-principals/INDEX.md b/rap/service-principals/INDEX.md index 91304a50..a7fe2c58 100644 --- a/rap/service-principals/INDEX.md +++ b/rap/service-principals/INDEX.md @@ -1,6 +1,6 @@ # Service Principals Documentation Index -Documentation for C1 service principals and workload federation. Request relevant sections based on user's question. +Documentation for C1.ai service principals and workload federation. Request relevant sections based on user's question. ## How to Use @@ -97,7 +97,7 @@ Documentation for C1 service principals and workload federation. Request relevan User: "How do I authenticate from GitHub Actions?" Retrieve: `platform-github.md` -User: "Set up Terraform with C1" +User: "Set up Terraform with C1.ai" Retrieve: `auth-tools.md`, `platform-terraform.md` User: "How do I authenticate from AWS?" @@ -109,7 +109,7 @@ Retrieve: `manage-credentials.md` User: "CEL expression for specific repository" Retrieve: `security-cel.md`, `platform-github.md` -User: "What environment variables does C1 use?" +User: "What environment variables does C1.ai use?" Retrieve: `concepts-env-vars.md` User: "Difference between client credentials and workload federation" diff --git a/rap/service-principals/auth-tools.md b/rap/service-principals/auth-tools.md index cdc21866..4cc27c94 100644 --- a/rap/service-principals/auth-tools.md +++ b/rap/service-principals/auth-tools.md @@ -1,6 +1,6 @@ # Terraform and Cone CLI -Configure C1 tools with service principal credentials. +Configure C1.ai tools with service principal credentials. ## Terraform Provider diff --git a/rap/service-principals/concepts-env-vars.md b/rap/service-principals/concepts-env-vars.md index 097267a3..d434967e 100644 --- a/rap/service-principals/concepts-env-vars.md +++ b/rap/service-principals/concepts-env-vars.md @@ -1,6 +1,6 @@ # Environment Variables -All C1 client tools recognize these environment variables. +All C1.ai client tools recognize these environment variables. ## Variables diff --git a/rap/service-principals/concepts-overview.md b/rap/service-principals/concepts-overview.md index 4d5bbc16..b3beefca 100644 --- a/rap/service-principals/concepts-overview.md +++ b/rap/service-principals/concepts-overview.md @@ -1,6 +1,6 @@ # Service Principals Overview -Machine identities for C1 API automation. +Machine identities for C1.ai API automation. ## What Service Principals Are @@ -8,7 +8,7 @@ A service principal is a non-human identity for scripts, CI/CD pipelines, Terraf Each service principal has: - Display name and unique ID -- Assigned C1 roles (same as human users) +- Assigned C1.ai roles (same as human users) - One or more owners who manage it - Multiple credentials or federation trusts @@ -27,7 +27,7 @@ Each service principal has: | Aspect | Client Credentials | Workload Federation | |--------|-------------------|---------------------| -| How | Client ID + secret to token endpoint | External OIDC token exchanged for C1 token | +| How | Client ID + secret to token endpoint | External OIDC token exchanged for C1.ai token | | Secrets | Must store and rotate client secret | No secrets - uses CI/CD platform's OIDC | | Best for | Local dev, scripts, cron jobs | GitHub Actions, GitLab CI, HCP Terraform | | Lifetime | Max 180 days, must rotate | No credentials to manage | @@ -44,7 +44,7 @@ A single service principal can use both methods simultaneously. ## Requirements -- Feature must be enabled (contact C1 account team during early access) +- Feature must be enabled (contact C1.ai account team during early access) - Super Admin role required to create service principals ## Limits diff --git a/rap/service-principals/federation-overview.md b/rap/service-principals/federation-overview.md index 64081d12..b2676135 100644 --- a/rap/service-principals/federation-overview.md +++ b/rap/service-principals/federation-overview.md @@ -5,9 +5,9 @@ Secretless authentication using OIDC tokens from CI/CD platforms. ## How It Works 1. CI/CD platform issues signed JWT for current workflow run -2. Workflow sends JWT to C1 token exchange endpoint -3. C1 validates: issuer, signature, audience, freshness, CEL conditions -4. C1 issues short-lived access token scoped to service principal's roles +2. Workflow sends JWT to C1.ai token exchange endpoint +3. C1.ai validates: issuer, signature, audience, freshness, CEL conditions +4. C1.ai issues short-lived access token scoped to service principal's roles No secrets stored. OIDC token valid only for single CI/CD run. diff --git a/rap/service-principals/federation-setup.md b/rap/service-principals/federation-setup.md index 8bd684aa..9270e8f9 100644 --- a/rap/service-principals/federation-setup.md +++ b/rap/service-principals/federation-setup.md @@ -1,6 +1,6 @@ # Setting Up Federation -Create a provider and trust using the C1 wizard. +Create a provider and trust using the C1.ai wizard. ## Prerequisites diff --git a/rap/service-principals/manage-permissions.md b/rap/service-principals/manage-permissions.md index 39c597c2..87535692 100644 --- a/rap/service-principals/manage-permissions.md +++ b/rap/service-principals/manage-permissions.md @@ -36,6 +36,6 @@ Once created, Super Admin can assign owners who then manage independently. ## Assigning Roles -Service principals are assigned C1 roles like human users. Role assignment controlled by Super Admins. +Service principals are assigned C1.ai roles like human users. Role assignment controlled by Super Admins. Credentials and trusts can further restrict effective permissions via scoped roles (intersection of assigned roles and scoped roles). diff --git a/rap/service-principals/platform-aws.md b/rap/service-principals/platform-aws.md index 2a9709f5..d2c9ffed 100644 --- a/rap/service-principals/platform-aws.md +++ b/rap/service-principals/platform-aws.md @@ -17,7 +17,7 @@ aws iam enable-outbound-web-identity-federation aws iam get-outbound-web-identity-federation-info ``` -Returns account-specific issuer URL (e.g., `https://abc123-def456.tokens.sts.global.api.aws`). Use this as the provider issuer URL in C1. +Returns account-specific issuer URL (e.g., `https://abc123-def456.tokens.sts.global.api.aws`). Use this as the provider issuer URL in C1.ai. ### IAM permissions @@ -59,7 +59,7 @@ C1_ACCESS_TOKEN=$(curl -s -X POST \ | jq -r '.access_token') ``` -When using C1 tools (`cone`, Terraform provider), you must set these environment variables. Do not skip this step — the tools require both to be set to handle the token exchange internally: +When using C1.ai tools (`cone`, Terraform provider), you must set these environment variables. Do not skip this step — the tools require both to be set to handle the token exchange internally: ```bash export CONDUCTORONE_OIDC_TOKEN=$AWS_JWT diff --git a/rap/service-principals/platform-github.md b/rap/service-principals/platform-github.md index 1b82398c..b5aa68be 100644 --- a/rap/service-principals/platform-github.md +++ b/rap/service-principals/platform-github.md @@ -32,7 +32,7 @@ jobs: The action: 1. Requests GitHub OIDC token with tenant as audience -2. Exchanges for C1 access token +2. Exchanges for C1.ai access token 3. Exports `CONDUCTORONE_ACCESS_TOKEN` and `CONDUCTORONE_CLIENT_ID` 4. Masks token in logs 5. Cleans up when job finishes diff --git a/rap/service-principals/platform-terraform.md b/rap/service-principals/platform-terraform.md index 0ed278f6..7ed6a28c 100644 --- a/rap/service-principals/platform-terraform.md +++ b/rap/service-principals/platform-terraform.md @@ -1,6 +1,6 @@ # HCP Terraform Integration -C1 Terraform provider auto-detects HCP Terraform workload identity tokens. +C1.ai Terraform provider auto-detects HCP Terraform workload identity tokens. ## Prerequisites diff --git a/rap/service-principals/security-audit.md b/rap/service-principals/security-audit.md index e6c5859e..b1e1fce3 100644 --- a/rap/service-principals/security-audit.md +++ b/rap/service-principals/security-audit.md @@ -1,6 +1,6 @@ # Audit Events -All service principal and workload federation activity recorded in C1 system log. +All service principal and workload federation activity recorded in C1.ai system log. ## Authentication Events @@ -46,4 +46,4 @@ CRUD operations logged as OCSF API Activity events. ## Viewing Events -Navigate to system log in C1 admin console. +Navigate to system log in C1.ai admin console.