To successfully interact with the Sentient API, an API key must be both active and provisioned.
- Guild-Based Limits – While users can generate multiple keys, usage limits are enforced at the guild level, ensuring fair resource distribution.
- No Cross-Guild Sharing – API keys are bound to their issuing guild and cannot be transferred or used across different guilds.
Sentient AI API keys follow a structured format to ensure security and validity. Each key consists of three main parts:
- Prefix – Identifies the key type (e.g., fdev- for developer keys).
- Unique Identifier – A securely generated random string.
- Checksum – A cryptographic verification component ensuring integrity.
*Note: The actual key will be much longer for security purposes.
API keys are generated securely and cannot be modified. Users should keep them confidential and avoid sharing them publicly.
To authenticate API requests, API keys must be included in the Authorization header as a Bearer token. This method ensures secure communication between your application and the Sentient AI API.
When making a request to the Sentient AI API, include the API key in the Authorization header like this:
- Secure: Using the Bearer token method ensures that your API key is transmitted securely, without exposing it unnecessarily in the URL or other locations.
- Standardized: This method is widely used in APIs, making it easier for developers to implement and manage.
To provide granular control over the usage of API keys, endpoint access can be selected when generating a key. Each API key will be restricted to specific endpoints, ensuring that it can only interact with the selected parts of the Sentient AI API. Once set, the selected endpoints cannot be changed.
When creating an API key, you will be prompted to select which endpoints the key will be able to access. These selections will determine which parts of the API the key can interact with. For example:
- Chat – The key will only be able to interact with chat-related endpoints, such as /api/v1/chat/completions.
- Image – The key will only be able to interact with image-related endpoints, such as /api/v1/img.
Once the API key is generated, the endpoint selection cannot be altered. This ensures that each key is strictly bound to the selected endpoints, providing more security and control over your API access.
- Increased Security: By restricting keys to specific endpoints, even if a key is compromised, it can only be used for the authorized functionality, reducing security risks.
- Streamlined Permissions: You can ensure that each API key is tightly coupled with a particular set of actions, avoiding unnecessary access to unrelated endpoints.
- Controlled Environment: Perfect for environments where different keys need different levels of access. For example, you can have one key for chat-related functionality and another for image generation, keeping them isolated.
Let’s say your API includes the following endpoints:
- /api/v1/chat/completions – For generating chat responses.
- /api/v1/img – For generating AI images.
If you create an API key with access only to /api/v1/chat/completions, the key will not be able to access the /api/v1/img endpoint, even if it's requested. Once selected, this restriction is permanent for the key.
- No Changes After Creation: Once the endpoints are selected during the key creation process, they cannot be changed. If additional functionality is required, a new key must be generated.
- View and Monitor Access: You can view which endpoints are available to each key within your developer console, but no modifications can be made to the endpoint selection once the key is created.