carbon_ruby_sdk 0.1.0

data/spec/api/auth_api_spec.rb

@@ -0,0 +1,50 @@
+=begin
+#Carbon
+
+#Connect external data to LLMs, no matter the source.
+
+The version of the OpenAPI document: 1.0.0
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for Carbon::AuthApi
+describe 'AuthApi' do
+  before do
+    # run before each test
+    @api_instance = Carbon::AuthApi.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of AuthApi' do
+    it 'should create an instance of AuthApi' do
+      expect(@api_instance).to be_instance_of(Carbon::AuthApi)
+    end
+  end
+
+  # unit tests for get_access_token
+  # Get Access Token
+  # @param [Hash] opts the optional parameters
+  # @return [TokenResponse]
+  describe 'get_access_token test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for get_white_labeling
+  # Get White Labeling
+  # Returns whether or not the organization is white labeled and which integrations are white labeled  :param current_user: the current user :param db: the database session :return: a WhiteLabelingResponse
+  # @param [Hash] opts the optional parameters
+  # @return [WhiteLabelingResponse]
+  describe 'get_white_labeling test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+end

data/spec/api/data_sources_api_spec.rb

@@ -0,0 +1,51 @@
+=begin
+#Carbon
+
+#Connect external data to LLMs, no matter the source.
+
+The version of the OpenAPI document: 1.0.0
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for Carbon::DataSourcesApi
+describe 'DataSourcesApi' do
+  before do
+    # run before each test
+    @api_instance = Carbon::DataSourcesApi.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of DataSourcesApi' do
+    it 'should create an instance of DataSourcesApi' do
+      expect(@api_instance).to be_instance_of(Carbon::DataSourcesApi)
+    end
+  end
+
+  # unit tests for query_user_data_sources
+  # User Data Sources
+  # @param organization_user_data_source_query_input 
+  # @param [Hash] opts the optional parameters
+  # @return [OrganizationUserDataSourceResponse]
+  describe 'query_user_data_sources test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for revoke_access_token
+  # Revoke Access Token
+  # @param revoke_access_token_input 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'revoke_access_token test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+end

data/spec/api/embeddings_api_spec.rb

@@ -0,0 +1,63 @@
+=begin
+#Carbon
+
+#Connect external data to LLMs, no matter the source.
+
+The version of the OpenAPI document: 1.0.0
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for Carbon::EmbeddingsApi
+describe 'EmbeddingsApi' do
+  before do
+    # run before each test
+    @api_instance = Carbon::EmbeddingsApi.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of EmbeddingsApi' do
+    it 'should create an instance of EmbeddingsApi' do
+      expect(@api_instance).to be_instance_of(Carbon::EmbeddingsApi)
+    end
+  end
+
+  # unit tests for get_documents
+  # Embeddings
+  # For pre-filtering documents, using `tags_v2` is preferred to using `tags` (which is now deprecated). If both `tags_v2` and `tags` are specified, `tags` is ignored. `tags_v2` enables building complex filters through the use of \"AND\", \"OR\", and negation logic. Take the below input as an example: ```json {     \"OR\": [         {             \"key\": \"subject\",             \"value\": \"holy-bible\",             \"negate\": false         },         {             \"key\": \"person-of-interest\",             \"value\": \"jesus christ\",             \"negate\": false         },         {             \"key\": \"genre\",             \"value\": \"religion\",             \"negate\": true         }         {             \"AND\": [                 {                     \"key\": \"subject\",                     \"value\": \"tao-te-ching\",                     \"negate\": false                 },                 {                     \"key\": \"author\",                     \"value\": \"lao-tzu\",                     \"negate\": false                 }             ]         }     ] } ``` In this case, files will be filtered such that: 1. \"subject\" = \"holy-bible\" OR 2. \"person-of-interest\" = \"jesus christ\" OR 3. \"genre\" != \"religion\" OR 4. \"subject\" = \"tao-te-ching\" AND \"author\" = \"lao-tzu\"  Note that the top level of the query must be either an \"OR\" or \"AND\" array. Currently, nesting is limited to 3. For tag blocks (those with \"key\", \"value\", and \"negate\" keys), the following typing rules apply: 1. \"key\" isn't optional and must be a `string` 2. \"value\" isn't optional and can be `any` or list[`any`] 3. \"negate\" is optional and must be `true` or `false`. If present and `true`, then the filter block is negated in the resulting query. It is `false` by default.   When querying embeddings, you can optionally specify the `media_type` parameter in your request. By default (if not set), it is equal to \"TEXT\". This means that the query will be performed over files that have been parsed as text (for now, this covers all files except image files). If it is equal to \"IMAGE\", the query will be performed over image files (for now, `.jpg` and `.png` files). You can think of this field as an additional filter on top of any filters set in `file_ids` and   When `hybrid_search` is set to true, a combination of keyword search and semantic search are used to rank and select candidate embeddings during information retrieval. By default, these search methods are weighted equally during the ranking process. To adjust the weight (or \"importance\") of each search method, you can use the `hybrid_search_tuning_parameters` property. The description for the different tuning parameters are: - `weight_a`: weight to assign to semantic search - `weight_b`: weight to assign to keyword search  You must ensure that `sum(weight_a, weight_b,..., weight_n)` for all *n* weights is equal to 1. The equality has an error tolerance of 0.001 to account for possible floating point issues.  In order to use hybrid search for a customer across a set of documents, two flags need to be enabled: 1. Use the `/modify_user_configuration` endpoint to to enable `sparse_vectors` for the customer. The payload body for this request is below: ``` {   \"configuration_key_name\": \"sparse_vectors\",   \"value\": {     \"enabled\": true   } } ``` 2. Make sure hybrid search is enabled for the documents across which you want to perform the search. For the `/uploadfile` endpoint, this can be done by setting the following query parameter: `generate_sparse_vectors=true`   Carbon supports multiple models for use in generating embeddings for files. For images, we support Vertex AI's multimodal model; for text, we support OpenAI's `text-embedding-ada-002` and Cohere's embed-multilingual-v3.0. The model can be specified via the `embedding_model` parameter (in the POST body for `/embeddings`, and a query  parameter in `/uploadfile`). If no model is supplied, the `text-embedding-ada-002` is used by default. When performing embedding queries, embeddings from files that used the specified model will be considered in the query. For example, if files A and B have embeddings generated with `OPENAI`, and files C and D have embeddings generated with `COHERE_MULTILINGUAL_V3`, then by default, queries will only consider files A and B. If `COHERE_MULTILINGUAL_V3` is specified as the `embedding_model` in `/embeddings`, then only files C and D will be considered. Make sure that the set of all files you want considered for a query have embeddings generated via the same model. For now, **do not** set `VERTEX_MULTIMODAL` as an `embedding_model`. This model is used automatically by Carbon when it detects an image file.
+  # @param get_embedding_documents_body 
+  # @param [Hash] opts the optional parameters
+  # @return [DocumentResponseList]
+  describe 'get_documents test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for get_embeddings_and_chunks
+  # Retrieve Embeddings And Content
+  # @param embeddings_and_chunks_query_input 
+  # @param [Hash] opts the optional parameters
+  # @return [EmbeddingsAndChunksResponse]
+  describe 'get_embeddings_and_chunks test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for upload_chunks_and_embeddings
+  # Upload Chunks And Embeddings
+  # @param chunks_and_embeddings_upload_input 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'upload_chunks_and_embeddings test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+end

data/spec/api/files_api_spec.rb

@@ -0,0 +1,178 @@
+=begin
+#Carbon
+
+#Connect external data to LLMs, no matter the source.
+
+The version of the OpenAPI document: 1.0.0
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for Carbon::FilesApi
+describe 'FilesApi' do
+  before do
+    # run before each test
+    @api_instance = Carbon::FilesApi.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of FilesApi' do
+    it 'should create an instance of FilesApi' do
+      expect(@api_instance).to be_instance_of(Carbon::FilesApi)
+    end
+  end
+
+  # unit tests for create_user_file_tags
+  # Create File Tags
+  # A tag is a key-value pair that can be added to a file. This pair can then be used for searches (e.g. embedding searches) in order to narrow down the scope of the search. A file can have any number of tags. The following are reserved keys that cannot be used: - db_embedding_id - organization_id - user_id - organization_user_file_id  Carbon currently supports two data types for tag values - `string` and `list<string>`. Keys can only be `string`. If values other than `string` and `list<string>` are used, they're automatically converted to strings (e.g. 4 will become \"4\").
+  # @param organization_user_file_tag_create 
+  # @param [Hash] opts the optional parameters
+  # @return [UserFile]
+  describe 'create_user_file_tags test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for delete
+  # Delete File Endpoint
+  # @param file_id 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'delete test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for delete_file_tags
+  # Delete File Tags
+  # @param organization_user_file_tags_remove 
+  # @param [Hash] opts the optional parameters
+  # @return [UserFile]
+  describe 'delete_file_tags test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for delete_many
+  # Delete Files Endpoint
+  # @param delete_files_query_input 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'delete_many test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for get_parsed_file
+  # Parsed File
+  # This route is deprecated. Use `/user_files_v2` instead.
+  # @param file_id 
+  # @param [Hash] opts the optional parameters
+  # @return [PresignedURLResponse]
+  describe 'get_parsed_file test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for get_raw_file
+  # Raw File
+  # This route is deprecated. Use `/user_files_v2` instead.
+  # @param file_id 
+  # @param [Hash] opts the optional parameters
+  # @return [PresignedURLResponse]
+  describe 'get_raw_file test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for query_user_files
+  # User Files V2
+  # For pre-filtering documents, using `tags_v2` is preferred to using `tags` (which is now deprecated). If both `tags_v2` and `tags` are specified, `tags` is ignored. `tags_v2` enables building complex filters through the use of \"AND\", \"OR\", and negation logic. Take the below input as an example: ```json {     \"OR\": [         {             \"key\": \"subject\",             \"value\": \"holy-bible\",             \"negate\": false         },         {             \"key\": \"person-of-interest\",             \"value\": \"jesus christ\",             \"negate\": false         },         {             \"key\": \"genre\",             \"value\": \"religion\",             \"negate\": true         }         {             \"AND\": [                 {                     \"key\": \"subject\",                     \"value\": \"tao-te-ching\",                     \"negate\": false                 },                 {                     \"key\": \"author\",                     \"value\": \"lao-tzu\",                     \"negate\": false                 }             ]         }     ] } ``` In this case, files will be filtered such that: 1. \"subject\" = \"holy-bible\" OR 2. \"person-of-interest\" = \"jesus christ\" OR 3. \"genre\" != \"religion\" OR 4. \"subject\" = \"tao-te-ching\" AND \"author\" = \"lao-tzu\"  Note that the top level of the query must be either an \"OR\" or \"AND\" array. Currently, nesting is limited to 3. For tag blocks (those with \"key\", \"value\", and \"negate\" keys), the following typing rules apply: 1. \"key\" isn't optional and must be a `string` 2. \"value\" isn't optional and can be `any` or list[`any`] 3. \"negate\" is optional and must be `true` or `false`. If present and `true`, then the filter block is negated in the resulting query. It is `false` by default.
+  # @param organization_user_files_to_sync_query_input 
+  # @param [Hash] opts the optional parameters
+  # @return [UserFilesV2]
+  describe 'query_user_files test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for query_user_files_deprecated
+  # User Files
+  # This route is deprecated. Use `/user_files_v2` instead.
+  # @param organization_user_files_to_sync_query_input 
+  # @param [Hash] opts the optional parameters
+  # @return [Array<UserFile>]
+  describe 'query_user_files_deprecated test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for resync
+  # Resync File
+  # @param resync_file_query_input 
+  # @param [Hash] opts the optional parameters
+  # @return [UserFile]
+  describe 'resync test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for upload
+  # Create Upload File
+  # This endpoint is used to directly upload local files to Carbon. The &#x60;POST&#x60; request should be a multipart form request. Note that the &#x60;set_page_as_boundary&#x60; query parameter is applicable only to PDFs for now. When this value is set, PDF chunks are at most one page long. Additional information can be retrieved for each chunk, however, namely the coordinates of the bounding box around the chunk (this can be used for things like text highlighting). Following is a description of all possible query parameters: - &#x60;chunk_size&#x60;: the chunk size (in tokens) applied when splitting the document - &#x60;chunk_overlap&#x60;: the chunk overlap (in tokens) applied when splitting the document - &#x60;skip_embedding_generation&#x60;: whether or not to skip the generation of chunks and embeddings - &#x60;set_page_as_boundary&#x60;: described above - &#x60;embedding_model&#x60;: the model used to generate embeddings for the document chunks - &#x60;use_ocr&#x60;: whether or not to use OCR as a preprocessing step prior to generating chunks (only valid for PDFs currently) - &#x60;generate_sparse_vectors&#x60;: whether or not to generate sparse vectors for the file. Required for hybrid search. - &#x60;prepend_filename_to_chunks&#x60;: whether or not to prepend the filename to the chunk text   Carbon supports multiple models for use in generating embeddings for files. For images, we support Vertex AI&#39;s multimodal model; for text, we support OpenAI&#39;s &#x60;text-embedding-ada-002&#x60; and Cohere&#39;s embed-multilingual-v3.0. The model can be specified via the &#x60;embedding_model&#x60; parameter (in the POST body for &#x60;/embeddings&#x60;, and a query  parameter in &#x60;/uploadfile&#x60;). If no model is supplied, the &#x60;text-embedding-ada-002&#x60; is used by default. When performing embedding queries, embeddings from files that used the specified model will be considered in the query. For example, if files A and B have embeddings generated with &#x60;OPENAI&#x60;, and files C and D have embeddings generated with &#x60;COHERE_MULTILINGUAL_V3&#x60;, then by default, queries will only consider files A and B. If &#x60;COHERE_MULTILINGUAL_V3&#x60; is specified as the &#x60;embedding_model&#x60; in &#x60;/embeddings&#x60;, then only files C and D will be considered. Make sure that the set of all files you want considered for a query have embeddings generated via the same model. For now, **do not** set &#x60;VERTEX_MULTIMODAL&#x60; as an &#x60;embedding_model&#x60;. This model is used automatically by Carbon when it detects an image file.
+  # @param file 
+  # @param body_create_upload_file_uploadfile_post 
+  # @param [Hash] opts the optional parameters
+  # @option opts [Integer] :chunk_size Chunk size in tiktoken tokens to be used when processing file.
+  # @option opts [Integer] :chunk_overlap Chunk overlap in tiktoken tokens to be used when processing file.
+  # @option opts [Boolean] :skip_embedding_generation Flag to control whether or not embeddings should be generated and stored             when processing file.
+  # @option opts [Boolean] :set_page_as_boundary Flag to control whether or not to set the a page&#39;s worth of content as the maximum             amount of content that can appear in a chunk. Only valid for PDFs. See description route description for             more information.
+  # @option opts [TextEmbeddingGenerators] :embedding_model Embedding model that will be used to embed file chunks.
+  # @option opts [Boolean] :use_ocr Whether or not to use OCR when processing files. Only valid for PDFs. Useful for documents with             tables, images, and/or scanned text.
+  # @option opts [Boolean] :generate_sparse_vectors Whether or not to generate sparse vectors for the file. This is *required* for the file to be a             candidate for hybrid search.
+  # @option opts [Boolean] :prepend_filename_to_chunks Whether or not to prepend the file&#39;s name to chunks.
+  # @option opts [Integer] :max_items_per_chunk Number of objects per chunk. For json files only.
+  # @return [UserFile]
+  describe 'upload test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for upload_from_url
+  # Create Upload File From Url
+  # @param upload_file_from_url_input 
+  # @param [Hash] opts the optional parameters
+  # @return [UserFile]
+  describe 'upload_from_url test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for upload_text
+  # Create Raw Text
+  # Carbon supports multiple models for use in generating embeddings for files. For images, we support Vertex AI&#39;s multimodal model; for text, we support OpenAI&#39;s &#x60;text-embedding-ada-002&#x60; and Cohere&#39;s embed-multilingual-v3.0. The model can be specified via the &#x60;embedding_model&#x60; parameter (in the POST body for &#x60;/embeddings&#x60;, and a query  parameter in &#x60;/uploadfile&#x60;). If no model is supplied, the &#x60;text-embedding-ada-002&#x60; is used by default. When performing embedding queries, embeddings from files that used the specified model will be considered in the query. For example, if files A and B have embeddings generated with &#x60;OPENAI&#x60;, and files C and D have embeddings generated with &#x60;COHERE_MULTILINGUAL_V3&#x60;, then by default, queries will only consider files A and B. If &#x60;COHERE_MULTILINGUAL_V3&#x60; is specified as the &#x60;embedding_model&#x60; in &#x60;/embeddings&#x60;, then only files C and D will be considered. Make sure that the set of all files you want considered for a query have embeddings generated via the same model. For now, **do not** set &#x60;VERTEX_MULTIMODAL&#x60; as an &#x60;embedding_model&#x60;. This model is used automatically by Carbon when it detects an image file.
+  # @param raw_text_input 
+  # @param [Hash] opts the optional parameters
+  # @return [UserFile]
+  describe 'upload_text test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+end

data/spec/api/health_api_spec.rb

@@ -0,0 +1,39 @@
+=begin
+#Carbon
+
+#Connect external data to LLMs, no matter the source.
+
+The version of the OpenAPI document: 1.0.0
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for Carbon::HealthApi
+describe 'HealthApi' do
+  before do
+    # run before each test
+    @api_instance = Carbon::HealthApi.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of HealthApi' do
+    it 'should create an instance of HealthApi' do
+      expect(@api_instance).to be_instance_of(Carbon::HealthApi)
+    end
+  end
+
+  # unit tests for check
+  # Health
+  # @param [Hash] opts the optional parameters
+  # @return [Object]
+  describe 'check test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+end

data/spec/api/integrations_api_spec.rb

@@ -0,0 +1,226 @@
+=begin
+#Carbon
+
+#Connect external data to LLMs, no matter the source.
+
+The version of the OpenAPI document: 1.0.0
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for Carbon::IntegrationsApi
+describe 'IntegrationsApi' do
+  before do
+    # run before each test
+    @api_instance = Carbon::IntegrationsApi.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of IntegrationsApi' do
+    it 'should create an instance of IntegrationsApi' do
+      expect(@api_instance).to be_instance_of(Carbon::IntegrationsApi)
+    end
+  end
+
+  # unit tests for connect_freshdesk
+  # Freshdesk Connect
+  # Refer this article to obtain an API key https://support.freshdesk.com/en/support/solutions/articles/215517. Make sure that your API key has the permission to read solutions from your account and you are on a <b>paid</b> plan. Once you have an API key, you can make a request to this endpoint along with your freshdesk domain. This will  trigger an automatic sync of the articles in your \"solutions\" tab. Additional parameters below can be used to associate  data with the synced articles or modify the sync behavior.
+  # @param fresh_desk_connect_request 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'connect_freshdesk test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for connect_gitbook
+  # Gitbook Connect
+  # You will need an access token to connect your Gitbook account. Note that the permissions will be defined by the user  generating access token so make sure you have the permission to access spaces you will be syncing.  Refer this article for more details https://developer.gitbook.com/gitbook-api/authentication. Additionally, you need to specify the name of organization you will be syncing data from.
+  # @param gitbook_connect_request 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'connect_gitbook test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for create_aws_iam_user
+  # S3 Auth
+  # Create a new IAM user with permissions to: <ol> <li>List all buckets.</li> <li>Read from the specific buckets and objects to sync with Carbon. Ensure any future buckets or objects carry  the same permissions.</li> </ol> Once created, generate an access key for this user and share the credentials with us. We recommend testing this key beforehand.
+  # @param s3_auth_request 
+  # @param [Hash] opts the optional parameters
+  # @return [OrganizationUserDataSourceAPI]
+  describe 'create_aws_iam_user test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for get_oauth_url
+  # Get Oauth Url
+  # @param o_auth_url_request 
+  # @param [Hash] opts the optional parameters
+  # @return [Object]
+  describe 'get_oauth_url test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for list_confluence_pages
+  # Confluence List
+  # To begin listing a user's Confluence pages, at least a `data_source_id` of a connected Confluence account must be specified. This base request returns a list of root pages for every space the user has access to in a Confluence instance. To traverse further down the user's page directory, additional requests to this endpoint can be made with the same `data_source_id` and with `parent_id` set to the id of page from a previous request. For convenience, the `has_children` property in each directory item in the response list will flag which pages will return non-empty lists of pages when set as the `parent_id`.
+  # @param list_request 
+  # @param [Hash] opts the optional parameters
+  # @return [ListResponse]
+  describe 'list_confluence_pages test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for list_data_source_items
+  # List Data Source Items
+  # @param list_data_source_items_request 
+  # @param [Hash] opts the optional parameters
+  # @return [ListDataSourceItemsResponse]
+  describe 'list_data_source_items test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for list_folders
+  # Outlook Folders
+  # After connecting your Outlook account, you can use this endpoint to list all of your folders on outlook. This includes  both system folders like \"inbox\" and user created folders.
+  # @param [Hash] opts the optional parameters
+  # @return [Object]
+  describe 'list_folders test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for list_gitbook_spaces
+  # Gitbook Spaces
+  # After connecting your Gitbook account, you can use this endpoint to list all of your spaces under current organization.
+  # @param data_source_id 
+  # @param [Hash] opts the optional parameters
+  # @return [Object]
+  describe 'list_gitbook_spaces test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for list_labels
+  # Gmail Labels
+  # After connecting your Gmail account, you can use this endpoint to list all of your labels. User created labels will have the type \"user\" and Gmail's default labels will have the type \"system\"
+  # @param [Hash] opts the optional parameters
+  # @return [Object]
+  describe 'list_labels test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for sync_confluence
+  # Confluence Sync
+  # After listing pages in a user's Confluence account, the set of selected page `ids` and the connected account's `data_source_id` can be passed into this endpoint to sync them into Carbon. Additional parameters listed below can be used to associate data to the selected pages or alter the behavior of the sync.
+  # @param sync_files_request 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'sync_confluence test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for sync_data_source_items
+  # Sync Data Source Items
+  # @param sync_directory_request 
+  # @param [Hash] opts the optional parameters
+  # @return [OrganizationUserDataSourceAPI]
+  describe 'sync_data_source_items test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for sync_files
+  # Sync Files
+  # @param sync_files_request 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'sync_files test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for sync_gitbook
+  # Gitbook Sync
+  # You can sync upto 20 Gitbook spaces at a time using this endpoint. Additional parameters below can be used to associate  data with the synced pages or modify the sync behavior.
+  # @param gitbook_sync_request 
+  # @param [Hash] opts the optional parameters
+  # @return [Object]
+  describe 'sync_gitbook test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for sync_gmail
+  # Gmail Sync
+  # Once you have successfully connected your gmail account, you can choose which emails to sync with us using the filters parameter. Filters is a JSON object with key value pairs. It also supports AND and OR operations. For now, we support a limited set of keys listed below.  <b>label</b>: Inbuilt Gmail labels, for example \"Important\" or a custom label you created.   <b>after</b> or <b>before</b>: A date in YYYY/mm/dd format (example 2023/12/31). Gets emails after/before a certain date. You can also use them in combination to get emails from a certain period.   <b>is</b>: Can have the following values - starred, important, snoozed, and unread    Using keys or values outside of the specified values can lead to unexpected behaviour.  An example of a basic query with filters can be ```json {     \"filters\": {             \"key\": \"label\",             \"value\": \"Test\"         } } ``` Which will list all emails that have the label \"Test\".  You can use AND and OR operation in the following way: ```json {     \"filters\": {         \"AND\": [             {                 \"key\": \"after\",                 \"value\": \"2024/01/07\"             },             {                 \"OR\": [                     {                         \"key\": \"label\",                         \"value\": \"Personal\"                     },                     {                         \"key\": \"is\",                         \"value\": \"starred\"                     }                 ]             }         ]     } } ``` This will return emails after 7th of Jan that are either starred or have the label \"Personal\".  Note that this is the highest level of nesting we support, i.e. you can't add more AND/OR filters within the OR filter in the above example.
+  # @param gmail_sync_input 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'sync_gmail test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for sync_outlook
+  # Outlook Sync
+  # Once you have successfully connected your Outlook account, you can choose which emails to sync with us using the filters and folder parameter. \"folder\" should be the folder you want to sync from Outlook. By default we get messages from your inbox folder.   Filters is a JSON object with key value pairs. It also supports AND and OR operations. For now, we support a limited set of keys listed below.  <b>category</b>: Custom categories that you created in Outlook.   <b>after</b> or <b>before</b>: A date in YYYY/mm/dd format (example 2023/12/31). Gets emails after/before a certain date. You can also use them in combination to get emails from a certain period.     <b>is</b>: Can have the following values: flagged     An example of a basic query with filters can be ```json {     \"filters\": {             \"key\": \"category\",             \"value\": \"Test\"         } } ``` Which will list all emails that have the category \"Test\".    Specifying a custom folder in the same query ```json {     \"folder\": \"Folder Name\",     \"filters\": {             \"key\": \"category\",             \"value\": \"Test\"         } } ```  You can use AND and OR operation in the following way: ```json {     \"filters\": {         \"AND\": [             {                 \"key\": \"after\",                 \"value\": \"2024/01/07\"             },             {                 \"OR\": [                     {                         \"key\": \"category\",                         \"value\": \"Personal\"                     },                     {                         \"key\": \"category\",                         \"value\": \"Test\"                     },                 ]             }         ]     } } ``` This will return emails after 7th of Jan that have either Personal or Test as category.  Note that this is the highest level of nesting we support, i.e. you can't add more AND/OR filters within the OR filter in the above example.
+  # @param outlook_sync_input 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'sync_outlook test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for sync_rss_feed
+  # Rss Feed
+  # @param rss_feed_input 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'sync_rss_feed test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+  # unit tests for sync_s3_files
+  # S3 Files
+  # After optionally loading the items via /integrations/items/sync and integrations/items/list, use the bucket name  and object key as the ID in this endpoint to sync them into Carbon. Additional parameters below can associate  data with the selected items or modify the sync behavior
+  # @param s3_file_sync_input 
+  # @param [Hash] opts the optional parameters
+  # @return [GenericSuccessResponse]
+  describe 'sync_s3_files test' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
+end