-
Notifications
You must be signed in to change notification settings - Fork 4
feat: enterprise api #42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
67df47c
bf18dde
1939749
ddbfc92
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,145 @@ | ||
| --- | ||
| title: "Speaker Reidentification (Alpha)" | ||
| description: "Learn how to use speaker reidentification to track and identify speakers across multiple audio files" | ||
| --- | ||
|
|
||
| # Speaker Reidentification (Alpha) | ||
|
|
||
|
|
||
| <Note> | ||
| This feature is on **Alpha** state. | ||
|
|
||
| We're looking for feedbacks to improve this feature, [share yours here](https://gladiaio.typeform.com/feedback?typeform-source=app.gladia.io). | ||
|
|
||
| </Note> | ||
|
|
||
| Speaker reidentification allows you to track and identify speakers across multiple audio files by maintaining a database of speaker voice signatures. This feature is particularly useful for organizations that need to analyze conversations from multiple recordings while maintaining speaker consistency. | ||
|
|
||
| ## Overview | ||
|
|
||
| When speaker reidentification is enabled, the system will: | ||
| 1. Extract voice signatures from speakers in the audio | ||
| 2. Compare these signatures with previously stored speakers | ||
| 3. Assign consistent identifiers to matching speakers | ||
| 4. Optionally save new speaker signatures for future identification | ||
|
|
||
| ## Configuration | ||
|
|
||
| To enable speaker reidentification, set `speaker_reidentification` to `true` in your API request and provide the configuration through `speaker_reidentification_config`: | ||
|
|
||
| ```json | ||
| { | ||
| "speaker_reidentification": true, | ||
| "speaker_reidentification_config": { | ||
| "filters": { | ||
| "customer_id": "123", | ||
| "company": "gladia", | ||
| "department": "tech" | ||
| }, | ||
| "save_new_speakers": true, | ||
| "save_new_speaker_similarity_threshold": 0.95, | ||
| "boost_uuids": [] | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ### Parameters | ||
|
|
||
| | Parameter | Type | Description | | ||
| |-----------|------|-------------| | ||
| | `speaker_reidentification` | boolean | Enable/disable speaker reidentification | | ||
| | `speaker_reidentification_config` | object | Configuration object for speaker reidentification | | ||
|
|
||
| ### Speaker Reidentification Config Options | ||
|
|
||
| | Option | Type | Description | | ||
| |--------|------|-------------| | ||
| | `filters` | object | Filters to scope the speaker database search | | ||
| | `filters.customer_id` | string | Example of parameter called "customer_id" for scoping speaker search to a specific customer | | ||
| | `filters.company` | string | Example of parameter called "company" or Company name for scoping speaker search to a specific company that might be customer of your organization | | ||
| | `filters.department` | string | Example of parameter called "department" or Department name for further scoping to a specific department within a company that might be customer of your organization | | ||
| | `filters.whatever` | string | Example of parameter for further whatever scoping you need | | ||
| | `save_new_speakers` | boolean | Whether to save new speaker signatures to the database | | ||
| | `save_new_speaker_similarity_threshold` | float | Minimum similarity threshold (0-1) for saving new speakers (if we don't find a match withing this threshold) | | ||
| | `boost_uuids` | array | List of speaker UUIDs to prioritize in matching | | ||
|
|
||
| ## Example Usage | ||
| We recommand activating the diarization and speaker reidentification features at the same time if you plan to identify mutliple speakers within the same audio. | ||
| Here's a complete example of using speaker reidentification with the API: | ||
|
|
||
| ```json | ||
| { | ||
| "sentences": false, | ||
| "diarization": true, | ||
| "speaker_reidentification": true, | ||
| "speaker_reidentification_config": { | ||
| "filters": {}, | ||
| "save_new_speakers": true, | ||
| "save_new_speaker_similarity_threshold": 0.95, | ||
| "boost_uuids": [] | ||
| }, | ||
| "audio_url": "https://files.gladia.io/example/audio-transcription/split_infinity.wav" | ||
| } | ||
| ``` | ||
|
|
||
| ### Example Output for a Known Speaker | ||
| ```json | ||
| "speaker_reidentification": { | ||
| "success": true, | ||
| "is_empty": false, | ||
| "results": { | ||
| "0": [ | ||
| { | ||
| "score": 1.0000001, | ||
| "created_at_timestamp": 1736419219.108255, | ||
| "updated_at_timestamp": null, | ||
| "created_at_iso": "2025-01-09T10:40:19.108256", | ||
| "updated_at_iso": null, | ||
| "last_accessed_timestamp": 1736419347.55111, | ||
| "last_accessed_iso": "2025-01-09T10:42:27.551116", | ||
| "is_new_speaker": false, | ||
| "uuid": "fc04030f-5ad4-46f6-b9a0-8c238675165f", | ||
| "filters": {} | ||
| } | ||
| // More matched speakers... | ||
| ] | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ### Example Output for an Unknown Speaker newly enrolled | ||
| ```json | ||
| "speaker_reidentification": { | ||
| "success": true, | ||
| "is_empty": false, | ||
| "results": { | ||
| "6": [ | ||
| { | ||
| "score": 1.0000001, | ||
| "created_at_timestamp": 1736419302.801952, | ||
| "updated_at_timestamp": null, | ||
| "created_at_iso": "2025-01-09T10:41:42.801953", | ||
| "updated_at_iso": null, | ||
| "last_accessed_timestamp": 1736419500.189427, | ||
| "last_accessed_iso": "2025-01-09T10:45:00.189431", | ||
| "is_new_speaker": true, # true if the speaker is not found in the database but has been enrolled | ||
| "uuid": "c24c1436-6139-46f9-bcd8-4d633889661a", | ||
| "filters": {} | ||
| } | ||
| ] | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ## Best Practices | ||
|
|
||
| 1. Always enable `diarization` when using speaker reidentification unless you have a specific reason not to (for instance speaker voiceprint registration) | ||
| 2. Use appropriate filters to narrow down the speaker database search scope | ||
| 3. Set a high `save_new_speaker_similarity_threshold` (e.g., 0.95) to ensure quality matches | ||
| 4. Use `boost_uuids` when you want to prioritize matching with specific known speakers | ||
|
|
||
| ## Limitations | ||
|
|
||
| - Speaker reidentification requires good quality audio for accurate matching | ||
| - Performance may vary based on audio quality and background noise | ||
| - The feature works best with clear speech and minimal overlapping voices | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,178 @@ | ||
| # Gladia Enterprise Portal API Documentation | ||
|
|
||
| ## Introduction | ||
|
|
||
| The Gladia Enterprise Portal API provides comprehensive functionality for managing subaccounts, API keys, usage monitoring, and data retention settings. This documentation covers all available endpoints and their usage. | ||
|
|
||
| ## Base URL | ||
|
|
||
| All API paths described below should be appended to your base API URL. | ||
|
|
||
| ## Authentication | ||
|
|
||
| Authentication details should be provided by your system administrator. | ||
|
Comment on lines
+11
to
+13
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🛠️ Refactor suggestion Authentication section needs more details. The authentication section should specify:
|
||
|
|
||
| ## API Endpoints | ||
|
|
||
| ### Subaccount Management | ||
|
|
||
| #### Create Subaccount | ||
| `POST /subaccount` | ||
|
|
||
| Creates a new subaccount in the system. | ||
|
|
||
| **Request Body:** | ||
| ```json | ||
| { | ||
| "email": "string", | ||
| "account_name": "string", | ||
| "usage_notification_threshold": "number", | ||
| "notification_emails": "string", | ||
| "monthly_limit_consumption_in_hours": "number" | ||
| } | ||
| ``` | ||
|
|
||
| All fields are required. | ||
|
|
||
| ### Notification Settings | ||
|
|
||
| #### Set Notification Emails | ||
| `POST /set-notification-emails` | ||
|
|
||
| Configure email notifications for a user account. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user | ||
| - `emails` (required): Comma-separated list of email addresses to receive notifications | ||
|
Comment on lines
+44
to
+46
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🛠️ Refactor suggestion Consider using path parameters instead of query parameters for resource identification. The API consistently uses email in query parameters to identify resources. Consider using path parameters instead, following REST conventions:
This approach is more RESTful and allows for better resource hierarchy. Also applies to: 53-55, 62-64, 73-74, 101-102, 109-110, 118-120, 128-130, 137-139, 148-150 |
||
|
|
||
| #### Set Monthly Limit Consumption | ||
| `POST /set-monthly-limit-consumption-in-hours` | ||
|
|
||
| Set the monthly usage limit for a user account. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user | ||
| - `limit` (required): Monthly limit in hours (numeric value) | ||
|
|
||
| #### Set Usage Notification Threshold | ||
| `POST /set-usage-notification-threshold` | ||
|
|
||
| Configure the threshold at which usage notifications are triggered. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user | ||
| - `threshold` (required): Threshold value (numeric) | ||
|
|
||
| ### Usage Monitoring | ||
|
|
||
| #### Get Account Consumption | ||
| `GET /consumption` | ||
|
|
||
| Retrieve consumption data for a specific account. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user to get consumption data for | ||
|
|
||
| #### Get All Accounts Consumption | ||
| `GET /consumptions` | ||
|
|
||
| Retrieve consumption data for all subaccounts under the master account. | ||
|
|
||
| #### Export Consumption Data | ||
| `GET /export-consumption-csv` | ||
|
|
||
| Export consumption data for a specific account in CSV format. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user | ||
|
|
||
| #### Export All Consumptions | ||
| `GET /export-consumptions-csv` | ||
|
|
||
| Export consumption data for all accounts in CSV format, with dates as rows and users as columns. | ||
|
|
||
| ### API Key Management | ||
|
|
||
| #### Get API Keys | ||
| `GET /account-api-keys` | ||
|
|
||
| Retrieve all API keys for an account. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user | ||
|
|
||
| #### Create API Key | ||
| `POST /account-api-keys` | ||
|
|
||
| Create a new API key for an account. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user | ||
| - `name` (optional): Name for the API key | ||
|
|
||
| #### Update API Key Name | ||
| `PATCH /account-api-keys` | ||
|
|
||
| Update the name of an existing API key. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user | ||
| - `api_key` (required): The API key to update | ||
| - `new_name` (required): New name for the API key | ||
|
|
||
| #### Delete API Key | ||
| `DELETE /account-api-keys` | ||
|
|
||
| Mark an API key as deleted. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user | ||
| - `api_key` (required): The API key to delete | ||
|
|
||
| #### Reactivate API Key | ||
| `PATCH /reactivate-account-api-key` | ||
|
|
||
| Reactivate a previously deleted API key. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user | ||
| - `api_key` (required): The API key to reactivate | ||
|
|
||
| ### Data Retention | ||
|
|
||
| #### Update Data Retention Period | ||
| `PATCH /user-data-retention` | ||
|
|
||
| Set the data retention period for a user account. | ||
|
|
||
| **Query Parameters:** | ||
| - `email` (required): The email of the user | ||
| - `data_retention_in_days` (required): Number of days to retain data | ||
|
|
||
| ## Error Handling | ||
|
|
||
| The API uses standard HTTP response codes to indicate success or failure of requests. In case of validation errors, the response will include detailed information about the error in the following format: | ||
|
|
||
| ```json | ||
| { | ||
| "detail": [ | ||
| { | ||
| "loc": ["field_name"], | ||
| "msg": "error message", | ||
| "type": "error type" | ||
| } | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| ## Best Practices | ||
|
|
||
| 1. Always handle API responses appropriately and check for error conditions | ||
| 2. Store API keys securely and never expose them in client-side code | ||
| 3. Implement proper retry logic for failed requests | ||
| 4. Monitor consumption regularly to avoid hitting usage limits | ||
| 5. Keep notification email lists up to date | ||
|
|
||
| ## Support | ||
|
|
||
| For additional support or questions about the API, please contact your account manager. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Add privacy and data retention information.
The limitations section should include information about: