hubspot-api-client 10.0.1 → 11.1.1

data/spec/codegen/cms/blogs/authors/api/{default_api_spec.rb → author_api_spec.rb}

@@ -13,22 +13,22 @@ OpenAPI Generator version: 4.3.1
 require 'spec_helper'
 require 'json'
 
-# Unit tests for Hubspot::Cms::Blogs::Authors::DefaultApi
+# Unit tests for Hubspot::Cms::Blogs::Authors::AuthorApi
 # Automatically generated by openapi-generator (https://openapi-generator.tech)
 # Please update as you see appropriate
-describe 'DefaultApi' do
+describe 'AuthorApi' do
   before do
     # run before each test
-    @api_instance = Hubspot::Cms::Blogs::Authors::DefaultApi.new
+    @api_instance = Hubspot::Cms::Blogs::Authors::AuthorApi.new
   end
 
   after do
     # run after each test
   end
 
-  describe 'test an instance of DefaultApi' do
-    it 'should create an instance of DefaultApi' do
-      expect(@api_instance).to be_instance_of(Hubspot::Cms::Blogs::Authors::DefaultApi)
+  describe 'test an instance of AuthorApi' do
+    it 'should create an instance of AuthorApi' do
+      expect(@api_instance).to be_instance_of(Hubspot::Cms::Blogs::Authors::AuthorApi)
     end
   end
 

data/spec/codegen/cms/blogs/blog-posts/api/{default_api_spec.rb → blog_post_api_spec.rb}

@@ -13,22 +13,22 @@ OpenAPI Generator version: 4.3.1
 require 'spec_helper'
 require 'json'
 
-# Unit tests for Hubspot::Cms::Blogs::BlogPosts::DefaultApi
+# Unit tests for Hubspot::Cms::Blogs::BlogPosts::BlogPostApi
 # Automatically generated by openapi-generator (https://openapi-generator.tech)
 # Please update as you see appropriate
-describe 'DefaultApi' do
+describe 'BlogPostApi' do
   before do
     # run before each test
-    @api_instance = Hubspot::Cms::Blogs::BlogPosts::DefaultApi.new
+    @api_instance = Hubspot::Cms::Blogs::BlogPosts::BlogPostApi.new
   end
 
   after do
     # run after each test
   end
 
-  describe 'test an instance of DefaultApi' do
-    it 'should create an instance of DefaultApi' do
-      expect(@api_instance).to be_instance_of(Hubspot::Cms::Blogs::BlogPosts::DefaultApi)
+  describe 'test an instance of BlogPostApi' do
+    it 'should create an instance of BlogPostApi' do
+      expect(@api_instance).to be_instance_of(Hubspot::Cms::Blogs::BlogPosts::BlogPostApi)
     end
   end
 

data/spec/codegen/cms/blogs/tags/api/{default_api_spec.rb → tag_api_spec.rb}

@@ -13,22 +13,22 @@ OpenAPI Generator version: 4.3.1
 require 'spec_helper'
 require 'json'
 
-# Unit tests for Hubspot::Cms::Blogs::Tags::DefaultApi
+# Unit tests for Hubspot::Cms::Blogs::Tags::TagApi
 # Automatically generated by openapi-generator (https://openapi-generator.tech)
 # Please update as you see appropriate
-describe 'DefaultApi' do
+describe 'TagApi' do
   before do
     # run before each test
-    @api_instance = Hubspot::Cms::Blogs::Tags::DefaultApi.new
+    @api_instance = Hubspot::Cms::Blogs::Tags::TagApi.new
   end
 
   after do
     # run after each test
   end
 
-  describe 'test an instance of DefaultApi' do
-    it 'should create an instance of DefaultApi' do
-      expect(@api_instance).to be_instance_of(Hubspot::Cms::Blogs::Tags::DefaultApi)
+  describe 'test an instance of TagApi' do
+    it 'should create an instance of TagApi' do
+      expect(@api_instance).to be_instance_of(Hubspot::Cms::Blogs::Tags::TagApi)
     end
   end
 

data/spec/codegen/cms/hubdb/api/rows_api_spec.rb

@@ -1,7 +1,7 @@
 =begin
 #HubDB endpoints
 
-#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `live` versions and you can publish and unpublish the live version. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, pushed to live version, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the live version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
+#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `published` versions. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the published version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
 
 The version of the OpenAPI document: v3
 
@@ -35,8 +35,8 @@ describe 'RowsApi' do
   # unit tests for clone_draft_table_row
   # Clone a row
   # Clones a single row in the `draft` version of the table.
-  # @param row_id The ID of the row
   # @param table_id_or_name The ID or name of the table
+  # @param row_id The ID of the row
   # @param [Hash] opts the optional parameters
   # @return [HubDbTableRowV3]
   describe 'clone_draft_table_row test' do
@@ -47,9 +47,9 @@ describe 'RowsApi' do
 
   # unit tests for create_table_row
   # Add a new row to a table
-  # Add a new row to a HubDB table. New rows will be added to the `draft` version of the table. Use `push-live` endpoint to push these changes to live version and publish them.
+  # Add a new row to a HubDB table. New rows will be added to the `draft` version of the table. Use `publish` endpoint to push these changes to published version.
   # @param table_id_or_name The ID or name of the target table.
-  # @param hub_db_table_row_v3_input The row definition JSON, formatted as described above.
+  # @param hub_db_table_row_v3_request The row definition JSON, formatted as described above.
   # @param [Hash] opts the optional parameters
   # @return [HubDbTableRowV3]
   describe 'create_table_row test' do
@@ -61,8 +61,8 @@ describe 'RowsApi' do
   # unit tests for get_draft_table_row_by_id
   # Get a row from the draft table
   # Get a single row by ID from a table's `draft` version.
-  # @param row_id The ID of the row
   # @param table_id_or_name The ID or name of the table
+  # @param row_id The ID of the row
   # @param [Hash] opts the optional parameters
   # @return [HubDbTableRowV3]
   describe 'get_draft_table_row_by_id test' do
@@ -73,9 +73,9 @@ describe 'RowsApi' do
 
   # unit tests for get_table_row
   # Get a table row
-  # Get a single row by ID from a table's `live` version. **Note:** This endpoint can be accessed without any authentication, if the table is set to be allowed for public access.
-  # @param row_id The ID of the row
+  # Get a single row by ID from a table's `published` version. **Note:** This endpoint can be accessed without any authentication, if the table is set to be allowed for public access.
   # @param table_id_or_name The ID or name of the table
+  # @param row_id The ID of the row
   # @param [Hash] opts the optional parameters
   # @return [HubDbTableRowV3]
   describe 'get_table_row test' do
@@ -86,13 +86,13 @@ describe 'RowsApi' do
 
   # unit tests for get_table_rows
   # Get rows for a table
-  # Returns a set of rows in the `live` version of the specified table. Row results can be filtered and sorted. Refer to the overview section for detailed filtering and sorting options. **Note:** This endpoint can be accessed without any authentication, if the table is set to be allowed for public access.
+  # Returns a set of rows in the `published` version of the specified table. Row results can be filtered and sorted. Filtering and sorting options will be sent as query parameters to the API request. For example, by adding the query parameters `column1__gt=5&sort=-column1`, API returns the rows with values for column `column1` greater than 5 and in the descending order of `column1` values. Refer to the [overview section](https://developers.hubspot.com/docs/api/cms/hubdb#filtering-and-sorting-table-rows) for detailed filtering and sorting options. **Note:** This endpoint can be accessed without any authentication, if the table is set to be allowed for public access.
   # @param table_id_or_name The ID or name of the table to query.
   # @param [Hash] opts the optional parameters
-  # @option opts [Array<String>] :properties Specify the column names to get results containing only the required columns instead of all column details.
+  # @option opts [Array<String>] :sort Specifies the column names to sort the results by. See the above description for more details.
   # @option opts [String] :after The cursor token value to get the next set of results. You can get this from the &#x60;paging.next.after&#x60; JSON property of a paged response containing more results.
   # @option opts [Integer] :limit The maximum number of results to return. Default is &#x60;1000&#x60;.
-  # @option opts [Array<String>] :sort Specifies the column names to sort the results by. See the above description for more details.
+  # @option opts [Array<String>] :properties Specify the column names to get results containing only the required columns instead of all column details.
   # @return [CollectionResponseWithTotalHubDbTableRowV3ForwardPaging]
   describe 'get_table_rows test' do
     it 'should work' do
@@ -103,8 +103,8 @@ describe 'RowsApi' do
   # unit tests for purge_draft_table_row
   # Permanently deletes a row
   # Permanently deletes a row from a table&#39;s &#x60;draft&#x60; version.
-  # @param row_id The ID of the row
   # @param table_id_or_name The ID or name of the table
+  # @param row_id The ID of the row
   # @param [Hash] opts the optional parameters
   # @return [nil]
   describe 'purge_draft_table_row test' do
@@ -115,13 +115,13 @@ describe 'RowsApi' do
 
   # unit tests for read_draft_table_rows
   # Get rows from draft table
-  # Returns rows in the &#x60;draft&#x60; version of the specified table. Row results can be filtered and sorted using the options mentioned in the overview section.
+  # Returns rows in the &#x60;draft&#x60; version of the specified table. Row results can be filtered and sorted. Filtering and sorting options will be sent as query parameters to the API request. For example, by adding the query parameters &#x60;column1__gt&#x3D;5&amp;sort&#x3D;-column1&#x60;, API returns the rows with values for column &#x60;column1&#x60; greater than 5 and in the descending order of &#x60;column1&#x60; values. Refer to the [overview section](https://developers.hubspot.com/docs/api/cms/hubdb#filtering-and-sorting-table-rows) for detailed filtering and sorting options.
   # @param table_id_or_name The ID or name of the table to query.
   # @param [Hash] opts the optional parameters
+  # @option opts [Array<String>] :sort Specifies the column names to sort the results by.
   # @option opts [String] :after The cursor token value to get the next set of results. You can get this from the &#x60;paging.next.after&#x60; JSON property of a paged response containing more results.
-  # @option opts [Array<String>] :properties Specify the column names to get results containing only the required columns instead of all column details. If you want to include multiple columns in the result, use this query param as many times. 
   # @option opts [Integer] :limit The maximum number of results to return. Default is &#x60;1000&#x60;.
-  # @option opts [Array<String>] :sort Specifies the column names to sort the results by.
+  # @option opts [Array<String>] :properties Specify the column names to get results containing only the required columns instead of all column details. If you want to include multiple columns in the result, use this query param as many times. 
   # @return [CollectionResponseWithTotalHubDbTableRowV3ForwardPaging]
   describe 'read_draft_table_rows test' do
     it 'should work' do
@@ -132,9 +132,9 @@ describe 'RowsApi' do
   # unit tests for replace_draft_table_row
   # Replaces an existing row
   # Replace a single row in the table&#39;s &#x60;draft&#x60; version. All the column values must be specified. If a column has a value in the target table and this request doesn&#39;t define that value, it will be deleted. See the &#x60;Create a row&#x60; endpoint for instructions on how to format the JSON row definitions.
-  # @param row_id The ID of the row
   # @param table_id_or_name The ID or name of the table
-  # @param hub_db_table_row_v3_input The JSON object of the row
+  # @param row_id The ID of the row
+  # @param hub_db_table_row_v3_request The JSON object of the row
   # @param [Hash] opts the optional parameters
   # @return [HubDbTableRowV3]
   describe 'replace_draft_table_row test' do
@@ -146,9 +146,9 @@ describe 'RowsApi' do
   # unit tests for update_draft_table_row
   # Updates an existing row
   # Sparse updates a single row in the table&#39;s &#x60;draft&#x60; version. All the column values need not be specified. Only the columns or fields that needs to be modified can be specified. See the &#x60;Create a row&#x60; endpoint for instructions on how to format the JSON row definitions.
-  # @param row_id The ID of the row
   # @param table_id_or_name The ID or name of the table
-  # @param hub_db_table_row_v3_input The JSON object of the row with necessary fields that needs to be updated.
+  # @param row_id The ID of the row
+  # @param hub_db_table_row_v3_request The JSON object of the row with necessary fields that needs to be updated.
   # @param [Hash] opts the optional parameters
   # @return [HubDbTableRowV3]
   describe 'update_draft_table_row test' do

data/spec/codegen/cms/hubdb/api/rows_batch_api_spec.rb

@@ -1,7 +1,7 @@
 =begin
 #HubDB endpoints
 
-#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `live` versions and you can publish and unpublish the live version. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, pushed to live version, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the live version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
+#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `published` versions. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the published version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
 
 The version of the OpenAPI document: v3
 
@@ -49,7 +49,7 @@ describe 'RowsBatchApi' do
   # Create rows in batch
   # Creates rows in the `draft` version of the specified table, given an array of row objects. See the overview section for more details with an example.
   # @param table_id_or_name The ID or name of the table
-  # @param batch_input_hub_db_table_row_v3 JSON array of row objects
+  # @param batch_input_hub_db_table_row_v3_request JSON array of row objects
   # @param [Hash] opts the optional parameters
   # @return [Object]
   describe 'batch_create_draft_table_rows test' do
@@ -86,7 +86,7 @@ describe 'RowsBatchApi' do
 
   # unit tests for batch_read_table_rows
   # Get a set of rows
-  # Returns rows in the `live` version of the specified table, given a set of row ids. **Note:** This endpoint can be accessed without any authentication if the table is set to be allowed for public access.
+  # Returns rows in the `published` version of the specified table, given a set of row ids. **Note:** This endpoint can be accessed without any authentication if the table is set to be allowed for public access.
   # @param table_id_or_name The ID or name of the table to query.
   # @param batch_input_string The JSON array of row ids
   # @param [Hash] opts the optional parameters
@@ -101,7 +101,7 @@ describe 'RowsBatchApi' do
   # Replace rows in batch in draft table
   # Replaces multiple rows as a batch in the `draft` version of the table. See the endpoint `PUT /tables/{tableIdOrName}/rows/{rowId}/draft` for details on updating a single row.
   # @param table_id_or_name The ID or name of the table
-  # @param batch_input_hub_db_table_row_v3 JSON array of row objects.
+  # @param batch_input_hub_db_table_row_v3_request JSON array of row objects.
   # @param [Hash] opts the optional parameters
   # @return [Object]
   describe 'batch_replace_draft_table_rows test' do

data/spec/codegen/cms/hubdb/api/tables_api_spec.rb

@@ -1,7 +1,7 @@
 =begin
 #HubDB endpoints
 
-#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `live` versions and you can publish and unpublish the live version. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, pushed to live version, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the live version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
+#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `published` versions. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the published version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
 
 The version of the OpenAPI document: v3
 
@@ -34,7 +34,7 @@ describe 'TablesApi' do
 
   # unit tests for archive_table
   # Archive a table
-  # Archive (soft delete) an existing HubDB table. This archives both the live and draft versions.
+  # Archive (soft delete) an existing HubDB table. This archives both the published and draft versions.
   # @param table_id_or_name The ID or name of the table to archive.
   # @param [Hash] opts the optional parameters
   # @return [nil]
@@ -60,7 +60,7 @@ describe 'TablesApi' do
   # unit tests for create_table
   # Create a new table
   # Creates a new draft HubDB table given a JSON schema. The table name and label should be unique for each account.
-  # @param hub_db_table_v3_input The JSON schema for the table being created.
+  # @param hub_db_table_v3_request The JSON schema for the table being created.
   # @param [Hash] opts the optional parameters
   # @return [HubDbTableV3]
   describe 'create_table test' do
@@ -84,7 +84,7 @@ describe 'TablesApi' do
 
   # unit tests for export_table
   # Export a published version of a table
-  # Exports the `live` version of a table to CSV / EXCEL format.
+  # Exports the `published` version of a table to CSV / EXCEL format.
   # @param table_id_or_name The ID or name of the table to export.
   # @param [Hash] opts the optional parameters
   # @option opts [String] :format The file format to export. Possible values include `CSV`, `XLSX`, and `XLS`.
@@ -99,16 +99,16 @@ describe 'TablesApi' do
   # Return all draft tables
   # Returns the details for each draft table defined in the specified account, including column definitions.
   # @param [Hash] opts the optional parameters
-  # @option opts [DateTime] :updated_after Only return tables last updated after the specified time.
-  # @option opts [DateTime] :updated_before Only return tables last updated before the specified time.
   # @option opts [Array<String>] :sort Specifies which fields to use for sorting results. Valid fields are &#x60;name&#x60;, &#x60;createdAt&#x60;, &#x60;updatedAt&#x60;, &#x60;createdBy&#x60;, &#x60;updatedBy&#x60;. &#x60;createdAt&#x60; will be used by default.
+  # @option opts [String] :after The cursor token value to get the next set of results. You can get this from the &#x60;paging.next.after&#x60; JSON property of a paged response containing more results.
+  # @option opts [Integer] :limit The maximum number of results to return. Default is 1000.
   # @option opts [DateTime] :created_at Only return tables created at exactly the specified time.
   # @option opts [DateTime] :created_after Only return tables created after the specified time.
-  # @option opts [String] :after The cursor token value to get the next set of results. You can get this from the &#x60;paging.next.after&#x60; JSON property of a paged response containing more results.
-  # @option opts [Boolean] :archived Specifies whether to return archived tables. Defaults to &#x60;false&#x60;.
   # @option opts [DateTime] :created_before Only return tables created before the specified time.
   # @option opts [DateTime] :updated_at Only return tables last updated at exactly the specified time.
-  # @option opts [Integer] :limit The maximum number of results to return. Default is 1000.
+  # @option opts [DateTime] :updated_after Only return tables last updated after the specified time.
+  # @option opts [DateTime] :updated_before Only return tables last updated before the specified time.
+  # @option opts [Boolean] :archived Specifies whether to return archived tables. Defaults to &#x60;false&#x60;.
   # @return [CollectionResponseWithTotalHubDbTableV3ForwardPaging]
   describe 'get_all_draft_tables test' do
     it 'should work' do
@@ -117,19 +117,19 @@ describe 'TablesApi' do
   end
 
   # unit tests for get_all_tables
-  # Get all live tables
-  # Returns the details for the &#x60;live&#x60; version of each table defined in an account, including column definitions.
+  # Get all published tables
+  # Returns the details for the &#x60;published&#x60; version of each table defined in an account, including column definitions.
   # @param [Hash] opts the optional parameters
-  # @option opts [DateTime] :updated_after Only return tables last updated after the specified time.
-  # @option opts [DateTime] :updated_before Only return tables last updated before the specified time.
   # @option opts [Array<String>] :sort Specifies which fields to use for sorting results. Valid fields are &#x60;name&#x60;, &#x60;createdAt&#x60;, &#x60;updatedAt&#x60;, &#x60;createdBy&#x60;, &#x60;updatedBy&#x60;. &#x60;createdAt&#x60; will be used by default.
+  # @option opts [String] :after The cursor token value to get the next set of results. You can get this from the &#x60;paging.next.after&#x60; JSON property of a paged response containing more results.
+  # @option opts [Integer] :limit The maximum number of results to return. Default is 1000.
   # @option opts [DateTime] :created_at Only return tables created at exactly the specified time.
   # @option opts [DateTime] :created_after Only return tables created after the specified time.
-  # @option opts [String] :after The cursor token value to get the next set of results. You can get this from the &#x60;paging.next.after&#x60; JSON property of a paged response containing more results.
-  # @option opts [Boolean] :archived Specifies whether to return archived tables. Defaults to &#x60;false&#x60;.
   # @option opts [DateTime] :created_before Only return tables created before the specified time.
   # @option opts [DateTime] :updated_at Only return tables last updated at exactly the specified time.
-  # @option opts [Integer] :limit The maximum number of results to return. Default is 1000.
+  # @option opts [DateTime] :updated_after Only return tables last updated after the specified time.
+  # @option opts [DateTime] :updated_before Only return tables last updated before the specified time.
+  # @option opts [Boolean] :archived Specifies whether to return archived tables. Defaults to &#x60;false&#x60;.
   # @return [CollectionResponseWithTotalHubDbTableV3ForwardPaging]
   describe 'get_all_tables test' do
     it 'should work' do
@@ -152,8 +152,8 @@ describe 'TablesApi' do
   end
 
   # unit tests for get_table_details
-  # Get details for a live table
-  # Returns the details for the &#x60;live&#x60; version of the specified table. This will include the definitions for the columns in the table and the number of rows in the table. **Note:** This endpoint can be accessed without any authentication if the table is set to be allowed for public access.
+  # Get details for a published table
+  # Returns the details for the &#x60;published&#x60; version of the specified table. This will include the definitions for the columns in the table and the number of rows in the table.  **Note:** This endpoint can be accessed without any authentication if the table is set to be allowed for public access.
   # @param table_id_or_name The ID or name of the table to return.
   # @param [Hash] opts the optional parameters
   # @option opts [Boolean] :archived Set this to &#x60;true&#x60; to return details for an archived table. Defaults to &#x60;false&#x60;.
@@ -167,11 +167,11 @@ describe 'TablesApi' do
 
   # unit tests for import_draft_table
   # Import data into draft table
-  # Import the contents of a CSV file into an existing HubDB table. The data will always be imported into the &#x60;draft&#x60; version of the table. Use &#x60;/push-live&#x60; endpoint to push these changes to &#x60;live&#x60; version. This endpoint takes a multi-part POST request. The first part will be a set of JSON-formatted options for the import and you can specify this with the name as &#x60;config&#x60;.  The second part will be the CSV file you want to import and you can specify this with the name as &#x60;file&#x60;. Refer the overview section to check the details and format of the JSON-formatted options for the import.
+  # Import the contents of a CSV file into an existing HubDB table. The data will always be imported into the &#x60;draft&#x60; version of the table. Use &#x60;/publish&#x60; endpoint to push these changes to &#x60;published&#x60; version. This endpoint takes a multi-part POST request. The first part will be a set of JSON-formatted options for the import and you can specify this with the name as &#x60;config&#x60;.  The second part will be the CSV file you want to import and you can specify this with the name as &#x60;file&#x60;. Refer the [overview section](https://developers.hubspot.com/docs/api/cms/hubdb#importing-tables) to check the details and format of the JSON-formatted options for the import.
   # @param table_id_or_name The ID of the destination table where data will be imported.
   # @param [Hash] opts the optional parameters
-  # @option opts [File] :file The source CSV file to be imported.
   # @option opts [String] :config Configuration for the import in JSON format as described above.
+  # @option opts [File] :file The source CSV file to be imported.
   # @return [ImportResult]
   describe 'import_draft_table test' do
     it 'should work' do
@@ -181,7 +181,7 @@ describe 'TablesApi' do
 
   # unit tests for publish_draft_table
   # Publish a table from draft
-  # Copies the data from draft to live version of the table and also publishes the live version. This will immediately push the data to the &#x60;live&#x60; version of the table and publishes the live version, meaning any website pages using data from the table will be updated.
+  # Publishes the table by copying the data and table schema changes from draft version to the published version, meaning any website pages using data from the table will be updated.
   # @param table_id_or_name The ID or name of the table to publish.
   # @param [Hash] opts the optional parameters
   # @option opts [Boolean] :include_foreign_ids Set this to &#x60;true&#x60; to populate foreign ID values in the response.
@@ -194,7 +194,7 @@ describe 'TablesApi' do
 
   # unit tests for reset_draft_table
   # Reset a draft table
-  # Replaces the data in the &#x60;draft&#x60; version of the table with values from the &#x60;live&#x60; version. Any unpublished changes in the &#x60;draft&#x60; will be lost after this call is made.
+  # Replaces the data in the &#x60;draft&#x60; version of the table with values from the &#x60;published&#x60; version. Any unpublished changes in the &#x60;draft&#x60; will be lost after this call is made.
   # @param table_id_or_name The ID or name of the table to reset.
   # @param [Hash] opts the optional parameters
   # @option opts [Boolean] :include_foreign_ids Set this to &#x60;true&#x60; to populate foreign ID values in the response.
@@ -205,30 +205,29 @@ describe 'TablesApi' do
     end
   end
 
-  # unit tests for update_draft_table
-  # Update an existing table
-  # Update an existing HubDB table. You can use this endpoint to add or remove columns to the table. Tables updated using the endpoint will only modify the &#x60;draft&#x60; verion of the table. Use &#x60;push-live&#x60; endpoint to push all the changes to the &#x60;live&#x60; version. **Note:** You need to include all the columns in the input when you are adding/removing/updating a column. If you do not include an already existing column in the request, it will be deleted.
-  # @param table_id_or_name The ID or name of the table to update.
-  # @param hub_db_table_v3_input The JSON schema for the table being updated.
+  # unit tests for unpublish_table
+  # Unpublish a table
+  # Unpublishes the table, meaning any website pages using data from the table will not render any data.
+  # @param table_id_or_name The ID or name of the table to publish.
   # @param [Hash] opts the optional parameters
-  # @option opts [Boolean] :include_foreign_ids Set this to &#x60;true&#x60; to populate foreign ID values in the result.
+  # @option opts [Boolean] :include_foreign_ids Set this to &#x60;true&#x60; to populate foreign ID values in the response.
   # @return [HubDbTableV3]
-  describe 'update_draft_table test' do
+  describe 'unpublish_table 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 update_table
-  # Publish or unpublish a live version of a table or restore an archived table
-  # Use this endpoint to perform one of the following &lt;ul&gt;&lt;li&gt; Publish a live version of a table (without copying table data from draft) &lt;/li&gt;&lt;li&gt;Un-publish a live version of a table (Leaving the data in the live version)&lt;/li&gt;&lt;li&gt;Restore an archived table&lt;/li&gt;&lt;/ul&gt;  To publish a table, send &#x60;published&#x60; property in the JSON object with the value &#x60;true&#x60;. To unpublish a table, send &#x60;published&#x60; property in the JSON object with the value &#x60;false&#x60;.  To restore an archived table, send &#x60;archived&#x60; property in the JSON object with the value &#x60;false&#x60; along with the query parameter &#x60;archived&#x3D;true&#x60;. When restoring an archived table, if an active table already exists with the same &#x60;name&#x60; or &#x60;label&#x60;, you will need to change the name of the archived table when restoring it using the &#x60;name&#x60; and &#x60;label&#x60; parameters with a new name and new label. When you restore a table, the table will be restored only in the &#x60;draft&#x60; version.  Examples:  Publish live version of a table:  &#x60;&#x60;&#x60;     {       \&quot;published\&quot;: true     } &#x60;&#x60;&#x60; Unpublish live version of a table: &#x60;&#x60;&#x60;     {       \&quot;published\&quot;: false     } &#x60;&#x60;&#x60; Restore a table: (send &#x60;archived&#x3D;true&#x60; in query parameters) &#x60;&#x60;&#x60;     {       \&quot;archived\&quot;: false     } &#x60;&#x60;&#x60; Restore a table with a new name: (send &#x60;archived&#x3D;true&#x60; in query parameters) &#x60;&#x60;&#x60;     {       \&quot;label\&quot;: \&quot;New Table Name\&quot;,       \&quot;name\&quot;: \&quot;new_table_name\&quot;,       \&quot;archived\&quot;: false     } &#x60;&#x60;&#x60;
-  # @param table_id_or_name The ID or name of the table to return.
-  # @param hub_db_table_v3_live_input The JSON object as described.
+  # unit tests for update_draft_table
+  # Update an existing table
+  # Update an existing HubDB table. You can use this endpoint to add or remove columns to the table as well as restore an archived table. Tables updated using the endpoint will only modify the &#x60;draft&#x60; verion of the table. Use &#x60;publish&#x60; endpoint to push all the changes to the &#x60;published&#x60; version. To restore a table, include the query parameter &#x60;archived&#x3D;true&#x60; and &#x60;\&quot;archived\&quot;: false&#x60; in the json body. **Note:** You need to include all the columns in the input when you are adding/removing/updating a column. If you do not include an already existing column in the request, it will be deleted.
+  # @param table_id_or_name The ID or name of the table to update.
+  # @param hub_db_table_v3_request The JSON schema for the table being updated.
   # @param [Hash] opts the optional parameters
-  # @option opts [Boolean] :archived Whether to return only results that have been archived.
+  # @option opts [Boolean] :archived Specifies whether to return archived tables. Defaults to &#x60;false&#x60;.
   # @option opts [Boolean] :include_foreign_ids Set this to &#x60;true&#x60; to populate foreign ID values in the result.
   # @return [HubDbTableV3]
-  describe 'update_table test' do
+  describe 'update_draft_table test' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end

data/spec/codegen/cms/hubdb/models/{batch_input_hub_db_table_row_v3_spec.rb → batch_input_hub_db_table_row_v3_request_spec.rb}

@@ -1,7 +1,7 @@
 =begin
 #HubDB endpoints
 
-#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `live` versions and you can publish and unpublish the live version. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, pushed to live version, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the live version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
+#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `published` versions. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the published version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
 
 The version of the OpenAPI document: v3
 
@@ -14,22 +14,22 @@ require 'spec_helper'
 require 'json'
 require 'date'
 
-# Unit tests for Hubspot::Cms::Hubdb::BatchInputHubDbTableRowV3
+# Unit tests for Hubspot::Cms::Hubdb::BatchInputHubDbTableRowV3Request
 # Automatically generated by openapi-generator (https://openapi-generator.tech)
 # Please update as you see appropriate
-describe 'BatchInputHubDbTableRowV3' do
+describe 'BatchInputHubDbTableRowV3Request' do
   before do
     # run before each test
-    @instance = Hubspot::Cms::Hubdb::BatchInputHubDbTableRowV3.new
+    @instance = Hubspot::Cms::Hubdb::BatchInputHubDbTableRowV3Request.new
   end
 
   after do
     # run after each test
   end
 
-  describe 'test an instance of BatchInputHubDbTableRowV3' do
-    it 'should create an instance of BatchInputHubDbTableRowV3' do
-      expect(@instance).to be_instance_of(Hubspot::Cms::Hubdb::BatchInputHubDbTableRowV3)
+  describe 'test an instance of BatchInputHubDbTableRowV3Request' do
+    it 'should create an instance of BatchInputHubDbTableRowV3Request' do
+      expect(@instance).to be_instance_of(Hubspot::Cms::Hubdb::BatchInputHubDbTableRowV3Request)
     end
   end
   describe 'test attribute "inputs"' do

data/spec/codegen/cms/hubdb/models/batch_input_json_node_spec.rb

@@ -1,7 +1,7 @@
 =begin
 #HubDB endpoints
 
-#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `live` versions and you can publish and unpublish the live version. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, pushed to live version, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the live version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
+#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `published` versions. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the published version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
 
 The version of the OpenAPI document: v3
 

data/spec/codegen/cms/hubdb/models/batch_input_string_spec.rb

@@ -1,7 +1,7 @@
 =begin
 #HubDB endpoints
 
-#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `live` versions and you can publish and unpublish the live version. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, pushed to live version, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the live version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
+#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `published` versions. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the published version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
 
 The version of the OpenAPI document: v3
 

data/spec/codegen/cms/hubdb/models/batch_response_hub_db_table_row_v3_with_errors_spec.rb

@@ -1,7 +1,7 @@
 =begin
 #HubDB endpoints
 
-#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `live` versions and you can publish and unpublish the live version. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, pushed to live version, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the live version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
+#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `published` versions. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the published version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
 
 The version of the OpenAPI document: v3
 

data/spec/codegen/cms/hubdb/models/collection_response_with_total_hub_db_table_row_v3_forward_paging_spec.rb

@@ -1,7 +1,7 @@
 =begin
 #HubDB endpoints
 
-#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `live` versions and you can publish and unpublish the live version. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, pushed to live version, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the live version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
+#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `published` versions. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the published version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
 
 The version of the OpenAPI document: v3
 

data/spec/codegen/cms/hubdb/models/collection_response_with_total_hub_db_table_v3_forward_paging_spec.rb

@@ -1,7 +1,7 @@
 =begin
 #HubDB endpoints
 
-#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `live` versions and you can publish and unpublish the live version. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, pushed to live version, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the live version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
+#HubDB is a relational data store that presents data as rows, columns, and cells in a table, much like a spreadsheet. HubDB tables can be added or modified [in the HubSpot CMS](https://knowledge.hubspot.com/cos-general/how-to-edit-hubdb-tables), but you can also use the API endpoints documented here. For more information on HubDB tables and using their data on a HubSpot site, see the [CMS developers site](https://designers.hubspot.com/docs/tools/hubdb). You can also see the [documentation for dynamic pages](https://designers.hubspot.com/docs/tutorials/how-to-build-dynamic-pages-with-hubdb) for more details about the `useForPages` field.  HubDB tables support `draft` and `published` versions. This allows you to update data in the table, either for testing or to allow for a manual approval process, without affecting any live pages using the existing data. Draft data can be reviewed, and published by a user working in HubSpot or published via the API. Draft data can also be discarded, allowing users to go back to the published version of the data without disrupting it. If a table is set to be `allowed for public access`, you can access the published version of the table and rows without any authentication by specifying the portal id via the query parameter `portalId`.
 
 The version of the OpenAPI document: v3