hubspot-api-client 10.1.1 → 11.2.0

data/spec/codegen/cms/hubdb/models/foreign_id_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/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/hub_db_table_clone_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
 

data/spec/codegen/cms/hubdb/models/{hub_db_table_row_v3_input_spec.rb → 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::HubDbTableRowV3Input
+# Unit tests for Hubspot::Cms::Hubdb::HubDbTableRowV3Request
 # Automatically generated by openapi-generator (https://openapi-generator.tech)
 # Please update as you see appropriate
-describe 'HubDbTableRowV3Input' do
+describe 'HubDbTableRowV3Request' do
   before do
     # run before each test
-    @instance = Hubspot::Cms::Hubdb::HubDbTableRowV3Input.new
+    @instance = Hubspot::Cms::Hubdb::HubDbTableRowV3Request.new
   end
 
   after do
     # run after each test
   end
 
-  describe 'test an instance of HubDbTableRowV3Input' do
-    it 'should create an instance of HubDbTableRowV3Input' do
-      expect(@instance).to be_instance_of(Hubspot::Cms::Hubdb::HubDbTableRowV3Input)
+  describe 'test an instance of HubDbTableRowV3Request' do
+    it 'should create an instance of HubDbTableRowV3Request' do
+      expect(@instance).to be_instance_of(Hubspot::Cms::Hubdb::HubDbTableRowV3Request)
     end
   end
   describe 'test attribute "path"' do
@@ -38,19 +38,19 @@ describe 'HubDbTableRowV3Input' do
     end
   end
 
-  describe 'test attribute "child_table_id"' do
+  describe 'test attribute "name"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "values"' do
+  describe 'test attribute "child_table_id"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "name"' do
+  describe 'test attribute "values"' 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/hub_db_table_row_v3_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
 
@@ -56,6 +56,12 @@ describe 'HubDbTableRowV3' do
     end
   end
 
+  describe 'test attribute "updated_at"' do
+    it 'should work' do
+      # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
+    end
+  end
+
   describe 'test attribute "child_table_id"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers

data/spec/codegen/cms/hubdb/models/{hub_db_table_v3_input_spec.rb → hub_db_table_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,31 +14,31 @@ require 'spec_helper'
 require 'json'
 require 'date'
 
-# Unit tests for Hubspot::Cms::Hubdb::HubDbTableV3Input
+# Unit tests for Hubspot::Cms::Hubdb::HubDbTableV3Request
 # Automatically generated by openapi-generator (https://openapi-generator.tech)
 # Please update as you see appropriate
-describe 'HubDbTableV3Input' do
+describe 'HubDbTableV3Request' do
   before do
     # run before each test
-    @instance = Hubspot::Cms::Hubdb::HubDbTableV3Input.new
+    @instance = Hubspot::Cms::Hubdb::HubDbTableV3Request.new
   end
 
   after do
     # run after each test
   end
 
-  describe 'test an instance of HubDbTableV3Input' do
-    it 'should create an instance of HubDbTableV3Input' do
-      expect(@instance).to be_instance_of(Hubspot::Cms::Hubdb::HubDbTableV3Input)
+  describe 'test an instance of HubDbTableV3Request' do
+    it 'should create an instance of HubDbTableV3Request' do
+      expect(@instance).to be_instance_of(Hubspot::Cms::Hubdb::HubDbTableV3Request)
     end
   end
-  describe 'test attribute "dynamic_meta_tags"' do
+  describe 'test attribute "name"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "allow_public_api_access"' do
+  describe 'test attribute "label"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
@@ -50,13 +50,13 @@ describe 'HubDbTableV3Input' do
     end
   end
 
-  describe 'test attribute "columns"' do
+  describe 'test attribute "allow_public_api_access"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "name"' do
+  describe 'test attribute "allow_child_tables"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
@@ -68,13 +68,13 @@ describe 'HubDbTableV3Input' do
     end
   end
 
-  describe 'test attribute "label"' do
+  describe 'test attribute "columns"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "allow_child_tables"' do
+  describe 'test attribute "dynamic_meta_tags"' 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/hub_db_table_v3_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/import_result_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/next_page_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/option_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/simple_user_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/standard_error_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/performance/api/{default_api_spec.rb → public_performance_api_spec.rb}

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

data/spec/codegen/cms/site-search/api/{default_api_spec.rb → public_api_spec.rb}

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

data/spec/codegen/cms/site-search/models/search_hit_field_spec.rb

@@ -32,13 +32,13 @@ describe 'SearchHitField' do
       expect(@instance).to be_instance_of(Hubspot::Cms::SiteSearch::SearchHitField)
     end
   end
-  describe 'test attribute "values"' do
+  describe 'test attribute "metadata_field"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end
   end
 
-  describe 'test attribute "metadata_field"' do
+  describe 'test attribute "values"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
     end

data/spec/codegen/crm/companies/api/batch_api_spec.rb

@@ -34,7 +34,6 @@ describe 'BatchApi' do
 
   # unit tests for archive
   # Archive a batch of companies by ID
-  # Archive a list of companies given a collection of IDs. This method will return a `204 No Content` response on success regardless of the initial state of the object (e.g. active, already archived, non-existent).
   # @param batch_input_simple_public_object_id 
   # @param [Hash] opts the optional parameters
   # @return [nil]
@@ -46,7 +45,6 @@ describe 'BatchApi' do
 
   # unit tests for create
   # Create a batch of companies
-  # Create a batch of companies. This follows the same rules as creating an individual object.
   # @param batch_input_simple_public_object_input 
   # @param [Hash] opts the optional parameters
   # @return [BatchResponseSimplePublicObject]
@@ -58,7 +56,6 @@ describe 'BatchApi' do
 
   # unit tests for read
   # Read a batch of companies by internal ID, or unique property values
-  # Read a list of companies given a collection of IDs. Use the `properties` request body property to control which properties are returned.
   # @param batch_read_input_simple_public_object_id 
   # @param [Hash] opts the optional parameters
   # @option opts [Boolean] :archived Whether to return only results that have been archived.
@@ -71,7 +68,6 @@ describe 'BatchApi' do
 
   # unit tests for update
   # Update a batch of companies
-  # Perform a partial upate on a batch of companies. This follows the same rules as performing partial updates on an individual object.
   # @param batch_input_simple_public_object_batch_input 
   # @param [Hash] opts the optional parameters
   # @return [BatchResponseSimplePublicObject]

data/spec/codegen/crm/companies/api/search_api_spec.rb

@@ -33,8 +33,6 @@ describe 'SearchApi' do
   end
 
   # unit tests for do_search
-  # Filter, Sort, and Search CRM Objects
-  # Filter, Sort, and Search CRM Objects
   # @param public_object_search_request 
   # @param [Hash] opts the optional parameters
   # @return [CollectionResponseWithTotalSimplePublicObjectForwardPaging]

data/spec/codegen/crm/companies/models/filter_spec.rb

@@ -47,7 +47,7 @@ describe 'Filter' do
   describe 'test attribute "operator"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
-      # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["EQ", "NEQ", "LT", "LTE", "GT", "GTE", "HAS_PROPERTY", "NOT_HAS_PROPERTY", "CONTAINS_TOKEN", "NOT_CONTAINS_TOKEN"])
+      # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["EQ", "NEQ", "LT", "LTE", "GT", "GTE", "BETWEEN", "IN", "NOT_IN", "HAS_PROPERTY", "NOT_HAS_PROPERTY", "CONTAINS_TOKEN", "NOT_CONTAINS_TOKEN"])
       # validator.allowable_values.each do |value|
       #   expect { @instance.operator = value }.not_to raise_error
       # end

data/spec/codegen/crm/contacts/api/batch_api_spec.rb

@@ -34,7 +34,6 @@ describe 'BatchApi' do
 
   # unit tests for archive
   # Archive a batch of contacts by ID
-  # Archive a list of contacts given a collection of IDs. This method will return a `204 No Content` response on success regardless of the initial state of the object (e.g. active, already archived, non-existent).
   # @param batch_input_simple_public_object_id 
   # @param [Hash] opts the optional parameters
   # @return [nil]
@@ -46,7 +45,6 @@ describe 'BatchApi' do
 
   # unit tests for create
   # Create a batch of contacts
-  # Create a batch of contacts. This follows the same rules as creating an individual object.
   # @param batch_input_simple_public_object_input 
   # @param [Hash] opts the optional parameters
   # @return [BatchResponseSimplePublicObject]
@@ -58,7 +56,6 @@ describe 'BatchApi' do
 
   # unit tests for read
   # Read a batch of contacts by internal ID, or unique property values
-  # Read a list of contacts given a collection of IDs. Use the `properties` request body property to control which properties are returned.
   # @param batch_read_input_simple_public_object_id 
   # @param [Hash] opts the optional parameters
   # @option opts [Boolean] :archived Whether to return only results that have been archived.
@@ -71,7 +68,6 @@ describe 'BatchApi' do
 
   # unit tests for update
   # Update a batch of contacts
-  # Perform a partial upate on a batch of contacts. This follows the same rules as performing partial updates on an individual object.
   # @param batch_input_simple_public_object_batch_input 
   # @param [Hash] opts the optional parameters
   # @return [BatchResponseSimplePublicObject]

data/spec/codegen/crm/contacts/api/gdpr_api_spec.rb

@@ -0,0 +1,59 @@
+=begin
+#Contacts
+
+#No description provided (generated by Openapi Generator https://github.com/openapitools/openapi-generator)
+
+The version of the OpenAPI document: v3
+
+Generated by: https://openapi-generator.tech
+OpenAPI Generator version: 4.3.1
+
+=end
+
+require 'spec_helper'
+require 'json'
+
+# Unit tests for Hubspot::Crm::Contacts::GDPRApi
+# Automatically generated by openapi-generator (https://openapi-generator.tech)
+# Please update as you see appropriate
+describe 'GDPRApi' do
+  before do
+    # run before each test
+    @api_instance = Hubspot::Crm::Contacts::GDPRApi.new
+  end
+
+  after do
+    # run after each test
+  end
+
+  describe 'test an instance of GDPRApi' do
+    it 'should create an instance of GDPRApi' do
+      expect(@api_instance).to be_instance_of(Hubspot::Crm::Contacts::GDPRApi)
+    end
+  end
+
+  # unit tests for purge_by_email
+  # DELETE
+  # Permanently delete a contact by email address and all associated content to follow GDPR. If contact isn't found, blacklists an email address from being used in the future.
+  # @param email 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'purge_by_email 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 purge_by_id
+  # DELETE
+  # Permanently delete a contact by id and all associated content to follow GDPR
+  # @param contact_id 
+  # @param [Hash] opts the optional parameters
+  # @return [nil]
+  describe 'purge_by_id 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/codegen/crm/contacts/api/search_api_spec.rb

@@ -33,8 +33,6 @@ describe 'SearchApi' do
   end
 
   # unit tests for do_search
-  # Filter, Sort, and Search CRM Objects
-  # Filter, Sort, and Search CRM Objects
   # @param public_object_search_request 
   # @param [Hash] opts the optional parameters
   # @return [CollectionResponseWithTotalSimplePublicObjectForwardPaging]

data/spec/codegen/crm/contacts/models/filter_spec.rb

@@ -47,7 +47,7 @@ describe 'Filter' do
   describe 'test attribute "operator"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
-      # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["EQ", "NEQ", "LT", "LTE", "GT", "GTE", "HAS_PROPERTY", "NOT_HAS_PROPERTY", "CONTAINS_TOKEN", "NOT_CONTAINS_TOKEN"])
+      # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["EQ", "NEQ", "LT", "LTE", "GT", "GTE", "BETWEEN", "IN", "NOT_IN", "HAS_PROPERTY", "NOT_HAS_PROPERTY", "CONTAINS_TOKEN", "NOT_CONTAINS_TOKEN"])
       # validator.allowable_values.each do |value|
       #   expect { @instance.operator = value }.not_to raise_error
       # end

data/spec/codegen/crm/deals/api/batch_api_spec.rb

@@ -34,7 +34,6 @@ describe 'BatchApi' do
 
   # unit tests for archive
   # Archive a batch of deals by ID
-  # Archive a list of deals given a collection of IDs. This method will return a `204 No Content` response on success regardless of the initial state of the object (e.g. active, already archived, non-existent).
   # @param batch_input_simple_public_object_id 
   # @param [Hash] opts the optional parameters
   # @return [nil]
@@ -46,7 +45,6 @@ describe 'BatchApi' do
 
   # unit tests for create
   # Create a batch of deals
-  # Create a batch of deals. This follows the same rules as creating an individual object.
   # @param batch_input_simple_public_object_input 
   # @param [Hash] opts the optional parameters
   # @return [BatchResponseSimplePublicObject]
@@ -58,7 +56,6 @@ describe 'BatchApi' do
 
   # unit tests for read
   # Read a batch of deals by internal ID, or unique property values
-  # Read a list of deals given a collection of IDs. Use the `properties` request body property to control which properties are returned.
   # @param batch_read_input_simple_public_object_id 
   # @param [Hash] opts the optional parameters
   # @option opts [Boolean] :archived Whether to return only results that have been archived.
@@ -71,7 +68,6 @@ describe 'BatchApi' do
 
   # unit tests for update
   # Update a batch of deals
-  # Perform a partial upate on a batch of deals. This follows the same rules as performing partial updates on an individual object.
   # @param batch_input_simple_public_object_batch_input 
   # @param [Hash] opts the optional parameters
   # @return [BatchResponseSimplePublicObject]

data/spec/codegen/crm/deals/api/search_api_spec.rb

@@ -33,8 +33,6 @@ describe 'SearchApi' do
   end
 
   # unit tests for do_search
-  # Filter, Sort, and Search CRM Objects
-  # Filter, Sort, and Search CRM Objects
   # @param public_object_search_request 
   # @param [Hash] opts the optional parameters
   # @return [CollectionResponseWithTotalSimplePublicObjectForwardPaging]

data/spec/codegen/crm/deals/models/filter_spec.rb

@@ -47,7 +47,7 @@ describe 'Filter' do
   describe 'test attribute "operator"' do
     it 'should work' do
       # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
-      # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["EQ", "NEQ", "LT", "LTE", "GT", "GTE", "HAS_PROPERTY", "NOT_HAS_PROPERTY", "CONTAINS_TOKEN", "NOT_CONTAINS_TOKEN"])
+      # validator = Petstore::EnumTest::EnumAttributeValidator.new('String', ["EQ", "NEQ", "LT", "LTE", "GT", "GTE", "BETWEEN", "IN", "NOT_IN", "HAS_PROPERTY", "NOT_HAS_PROPERTY", "CONTAINS_TOKEN", "NOT_CONTAINS_TOKEN"])
       # validator.allowable_values.each do |value|
       #   expect { @instance.operator = value }.not_to raise_error
       # end