Scope requirements
Scope requirements
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. Learn more about drafted versus live tables.
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 your HubSpot account ID via the query parameter portalId.
If you’re migrating from v2 of the HubDB API, learn more about the changes in the current (v3) API.
Rate limits
HubDB API requests have different rate limits, depending on the type of request:- Any
GETrequests made that don’t require authentication (including client-side JavaScript requests) are limited to 10 requests per second. These requests won’t count towards the daily limit. - All other requests using authentication follow the standard limits.
Draft vs live tables
HubDB tables have both draft and live versions and live versions can be published or unpublished. This will allow you to update data in the table, either for page previews or testing or to allow for a manual approval process, without affecting any live pages. In this API, separate endpoints are designated for the draft and published versions of a table. For example, you can retrieve the published version of a table by making aGET request to /cms/v3/hubdb/tables/{tableIdOrName}.
To retrieve any content that has been drafted but not yet published, you would add /draft to the end of the URL: /cms/v3/hubdb/tables/{tableIdOrName}/draft.
Draft data can be reviewed and then pushed in HubSpot, or with the /push-live endpoint. The draft data can also be discarded via the /reset endpoint, allowing you to revert to the current live version of the data without disruption.
Create a HubDB table
To create a HubDB table, make aPOST request to /cms/v3/hubdb/tables.
In the request body, specify the following required fields:
In addition, you can specify the following optional fields:
Without any columns added yet, your create request might look like the following:
Add table columns
Each column in a HubDB table can be defined with the following properties:
Using the above fields, your request to create a new HubDB table might look like the following:
id field in the input object.
Add table rows
You can add rows either manually through the API, or you can import rows from a CSV file. To add rows to a HubDB table, make aPOST request to /cms/v3/hubdb/tables/{tableIdOrName}/rows.
For each table row, you can include the following fields:
Using the above fields, your request might look similar to the following:
Import rows from CSV
To import data into a HubDB table from a CSV file, make aPOST request to /cms/v3/hubdb/tables/{tableIdOrName}/draft/import.
The import endpoint takes a multipart/form-data POST request:
config: a set of JSON-formatted options for the import.file: the CSV file that you want to import.
config, include the following fields as a JSON string:
Using the above table, your
config JSON might look like the following:
Date formatting
There are several formats you can use when importing data into a date-type column. Integersyyyy/mm/ddyyyy/mm/ddmm/dd/yyyymm/dd/yy
dd/mm/yy is not accepted). Integers can be separated by hyphens (-) or slashes (/).
Relaxed dates
You can also import date formats that are less standardized than integer-based dates. For example:
The 1st of March in the year 2022Fri Mar 4 2022March 4th '22
next ThursdayTodaytomorrow3 days from now
Reset options
When importing data from a CSV file into a HubDB table, you can set theresetTable field to true or false (default) to manage whether HubDB row data is overwritten.
-
If
resetTableis set totrue:- If the rows in the CSV file does not have a row ID column (
hs_idor row ID is specified as0, those rows will be inserted with the new row IDs generated. - If the row IDs in the CSV file already exists in the target table, the existing rows in the table will be updated with the new values from the input file.
- If the table has rows but the input CSV file does not have those row IDs, those rows will be deleted from the target table.
- If the row IDs in the input CSV file do not exist in the target table, those rows will be inserted with the new row IDs generated and the row IDs given in the input file will be ignored.
- If the input CSV file does not contain the row ID column at all, all the rows will be deleted from the target table and the rows from the input file will be inserted with the new row IDs generated.
- If the rows in the CSV file does not have a row ID column (
-
If
resetTableis set tofalse(default):- If the row IDs in the CSV file already exists in the target table, the existing rows in the table will be updated with the new values from the input file.
- If the table has rows but the input CSV file does not have those row IDs, those rows will not be deleted from the target table and those rows will remain unchanged.
- If the row IDs in the input CSV file do not exist in the target table, those rows will be inserted with the new row IDs generated and the row IDs given in the input file will be ignored.
- If the rows in the CSV file does not have a row ID column or row ID is specified as
0, those rows will be inserted with the new row IDs generated.
Retrieve HubDB data
There are multiple ways to retrieve HubDB data, depending on whether you’re looking for table details or the rows of a table:- To retrieve table details from all published tables, make a
GETrequest to/cms/v3/hubdb/tables. - To retrieve table details from a specific published table, make a
GETrequest to/cms/v3/hubdb/tables/{tableIdOrName}. - To retrieve all rows from a specific table, make a
GETrequest to/cms/v3/hubdb/tables/{tableIdOrName}/rows. - To retrieve a specific row from a table, make a
GETrequest to/cms/v3/hubdb/tables/{tableIdOrName}/rows/{rowId}.
portalId.
Filter returned rows
When retrieving HubDB table data, you can apply filters as query parameters to receive specific data. Filter query parameters are constructed as follows:columnName__operator.
For example, if you have a number column named bar, you can filter results to only include rows where bar is greater than 10: &bar__gt=10.
All filters are ANDed together (OR filters are not currently supported).
When filtering, keep the following in mind:
-
When passing values for
multiselectcolumns, the values should be comma-separated (e.g.multiselect_column__contains=1,2). -
For
datetimefilters, you can use relative dates in place of timestamps in order to specify a value relative to the current time. For example,-3hwould correspond to the timestamp 3 hours before now, whereas10swould correspond to 10 seconds in the future. Supported time units are ms (milliseconds), s (seconds), m (minutes), h (hours), d (days). Current time can be used by specifying a zero value: 0s -
For the purposes of these filters, the built in column
hs_idis anumbercolumn, thehs_created_atcolumn is adatetime, and thehs_pathandhs_namecolumns aretextcolumns.
Sort returned rows
When retrieving HubDB data, you can apply sorting as a query parameter to determine the order of the returned data. To sort data, add asort query parameter and specify the column name: &sort=columnName.
By default, data will be returned in the natural order of the specified column. You can reverse the sort by adding a - before the column name: &sort=-columnName.
You can include this parameter multiple times to sort by multiple columns.
In addition to sorting by a column, there are three functions that can be used:
-
geo_distance(location_column_name, latitude, longitude): takes the name of a location column and coordinates, returns the rows ordered by how far away the values of the specified location column are from the provided coordinates. -
length(column_name): takes the name of a column, returns the rows ordered by the length of the column value (calculated as a string) -
random(): returns the rows in random order.
geo_distance sort returns items that are the farthest away first:
sort=-geo_distance(location_column,42.37,-71.07)
Configuring HubDB tables for dynamic pages
Using HubSpot’s CMS, you can use a HubDB table as a data source to generate dynamic pages. For example, you can create a table that contains a row for each member of your executive team, with columns containing information that you want to display on a page. After selecting that table as the dynamic data source for a page, that page will generate a listing page that displays all rows as summary items, along with separate pages for each row, similar to a blog listing page and blog post pages. To enable a table to be selected as a data source in the content editor, you’ll need to setuseForPage to true. You can optionally include dynamicMetaTags to specify which columns to use for each page’s metadata.
For example, the code below would create a table that can be used for dynamic pages, and specifies the three columns to use for page metadata.
Changes in v3
- Tables should have both
nameandlabel. This name cannot be changed once the table is created. Names can only include lowercase letters, digits, and underscores and cannot begin with a number. Bothnameandlabelshould be unique in the account. - The API supports both table
idandnamein the URL paths. - The
GETrow endpoints return columnnameinstead ofidinvaluesfield. Also,POST/PUT/PATCHrow endpoints require columnnameinstead ofidinvaluesfield. - The row update
PATCHendpoints now accept sparse updates, which means you can specify only the column values that you need to update (whereas you had to specify all the column values in the previous versions). When you update a column with a list of values such as multiselect, you need to specify the list of all the values. In order to delete the value for a column, you need to specify the column with the value asnullin the request. - Removed the endpoints to
get/update/deletea row cell in favor of the row updatePATCHendpoints. - The import endpoint now supports an optional field
idSourceColumnalong with existing fields in the JSON-formatted options. You can use this field to specify the column in the CSV file which contains row IDs. To import new rows along with the new values for existing rows, specify0as the row ID for the new rows and the valid row IDs for the existing columns. Learn more about importing rows from CSV. Also you can use column names or IDs in the target field of the column mappings in the JSON-formatted options. - The clone endpoint requires a new name and new label to be set for the cloned table.