Skip to main content

Use this API to create, manage, and publish website and landing pages. Learn more about creating and customizing pages within HubSpot. For example, fetch a currently drafted page, then publish it so that it's live on your website.

The following properties are deprecated and no longer included within the response:

  • campaign_name
  • is_draft
  • style_override_id
  • meta_keywords

To retrieve an account's pages, make a GET request to cms/v3/pages/{landing-pages|site-pages}. You can filter and sort the returned pages by adding query parameters to the request URL, which are described below. For example, to retrieve all website pages that are currently published or scheduled to publish, you would make a GET request to the following URL:cms/v3/pages/site-pages?state__in=PUBLISHED_OR_SCHEDULEDYou'll receive a response containing information about the page, along with the page's content.

When retrieving pages, you can add query parameters to the request URL to filter the results. Each filter will follow the same general syntax: propertyName__operator=value. You can include as many filters as you'd like, and all specified filters will be applied to narrow down the results.For example, you can filter the results to only include pages where the name property contains the word marketing using this parameter: name__icontains=marketing.The table below lists the page properties that can be used as filters, along with which operators each property can use.

PropertyAvailable operators
ideq, in, not_in
slugeq, in, nin, icontains
campaigneq, in
stateeq, ne, in, nin, containsSee available states for filtering options.
publishDateeq, gt, gte, lt, lte
createdAteq, gt, gte, lt, lte
updatedAteq, gt, gte, lt, lte
templatePatheq, contains, startswith
nameeq, in, icontains
mabExperimentIdeq, in
abTestIdeq, in
archivedAteq, gt, gte, lt, lte
createdByIdeq
updatedByIdeq
domaineq, not_like, containsThis will display as blank for content published on a domain that is primary for that content type.
subcategoryeq, ne, in, nin
folderIdeq, in, null, not_null
languagein, not_null
translatedFromIdnull, not_null
dynamicPageHubDbTableIdeq, not_null

Below are the definitions for each operator, along with any available synonyms.

OperatorDescription
eqFilters for results that are equal to the specified value.Synonyms: exact, is
neFilters for results that are not equal to the specified value.Synonyms: neq, not
containsFilters for results that contain the specified, case-sensitive value. Not accepted for the name property.Synonym: like.
icontainsFilters for results by the specified value, not case sensitive. Synonym: ilike.
not_likeFilters for results that don't contain a specified value.Synonym: nlike
ltFilters for results that are less than a specified number value, such as a unix timestamp in milliseconds.
lteFilters for results that are less than or equal to a specified value.
gtFilters for results that are greater than a specified value.
gteFilters for results that are greater than or equal to a specified value.
is_nullFilters for results that do not have a value for the specified property.
not_nullFilters for results that have any value for the specified property.
startswithFilters for results that start with a specified value.
inIn
ninNot in

To retrieve pages with a given publish state, include the state__in= query parameter with the following values:

Draft: DRAFT, DRAFT_AB, DRAFT_AB_VARIANT, LOSER_AB_VARIANT

Scheduled: PUBLISHED_OR_SCHEDULED, SCHEDULED_AB

Published: PUBLISHED_OR_SCHEDULED, PUBLISHED_AB, PUBLISHED_AB_VARIANT

Because both scheduled and published pages will reflect a PUBLISHED_OR_SCHEDULED state, it's recommended to also include a publishDate parameter to better understand the page's current state.

For example, to identify the pages that are currently scheduled but not yet published, your request URL should include a publishDate parameter that uses the gt (greater than) operator with the current datetime specified. This will filter for pages with a publish time in the future: state__in=PUBLISHED_OR_SCHEDULED&publishDate__gt={currentTime}

To identify the pages that are already published, your request URL would similarly include a publishDate parameter, but you would use the lt (less than) operator with the current datetime specified. state__in=PUBLISHED_OR_SCHEDULED&publishDate__lt={currentTime}

When filtering for A/B test pages, you can use the following filters:

DescriptionQuery Params
Active A page or winning variant of a completed A/B testabStatus__eq=MASTER
Active B pageabStatus__eq=VARIANT
Losing variant of a completed A/B testabStatus__eq=LOSER_VARIANT

When filtering for multi-language pages, you can use the following filters:

DescriptionQuery Params
Primary page in a multi-language grouptranslatedFromId__is_null
Variation page in a multi-language grouptranslatedFromId__not_null
Page with specific Language* (German)language__in=deDoes not support language locale values (e.g., en-us)

To sort results, you can add a sort query parameter to your request URL, followed by the property name. You can reverse the sort by adding a - to the property name. For example: sort=-publishDate.By combining query parameters for filtering, sorting and paging, you can retrieve the pages that match your search criteria. For example, the request below fetches landing pages that do not have a language assigned, ordered by most recently updated. The limit and offset parameters below return the second page of results.

To create a website page, make a POST request to /cms/v3/pages/site-pages. In the request body, you'll include a JSON payload that sets the page's details along with the page content contained in the layoutSections object. The required fields when creating a page are name and templatePath.For templatePath, the path should not include a slash (/) at the start. When using the Copy path function in the design manager, this slash will be included automatically but should be removed after pasting it into your request body.To set the URL of a page, set the domain and slug fields. Note that the url field is generated and cannot be updated. Learn more about creating and customizing pages within HubSpot. You can create the page as a draft so that it's not yet published by setting the state to DRAFT. See available states for more information.

Pages in HubSpot have both draft and live versions. The draft version may be updated without affecting the live page content. Drafts can be reviewed and then published by a user working in HubSpot. They may also be scheduled for publication at a future time via the /schedule endpoint. Draft changes can be discarded via the /reset endpoint, allowing users to go back to the current live version of the page without disruption.

The draft version of a page can be updated via a PATCH request to the {objectid}/draft endpoint. This endpoint accepts a JSON payload representing the page model.Modifying the content of a page via these APIs is not recommended -- the content editor in HubSpot is the simplest way to modify website content.You can modify the widgets, widgetContainers, and layoutSections properties via this endpoint. They store page-level module data, contained directly in the template (widgets), within flex columns (widgetContainers) and in drag-and-drop areas (layoutSections).The properties provided in the supplied payload will override the existing draft properties without any complex merging logic. Consequently, when updating nested properties such as those within the widgets, widgetContainers, or layoutSections of the page, you must include the full definition of the object. Partial updates are not supported.

The draft version of a page can be reset to the current live version via a POST request to the {objectId}/draft/reset endpoint. This endpoint accepts no payload and simply reverts the draft version of the target page to match the current live version.

Unpublished changes to a published page can be pushed live via a POST request to the {objectId}/draft/push-live endpoint. This endpoint accepts no payload and will only update an already published page, not publish a drafted page.

The draft version of a page can be scheduled for publication at a future time via a POST request to the schedule endpoint. This endpoint accepts a JSON payload containing the id of the target page and a publishDate. Learn more about scheduling page publication.

A/B tests can be used to tune and optimize content by splitting traffic to a page across two variants of differing formats. Conversion rate of each page is monitored over time so that a winner can be chosen based on the relative success of each variant. Learn more about running A/B tests in HubSpot. The following properties will be populated on pages with active or completed A/B tests:

  • abTestId: Unique identifier for the page’s associated A/B test
  • abStatus: Indicates whether the page is an A/B primary, variant, or loser variant

An A/B test variant can be created via a POST request to the ab-test/create-variation endpoint. This endpoint accepts a JSON payload containing the contentId of the page to test and a variationName for the variant to be created.Upon creation, the new test variant can be updated and published in the same manner as a standard page.

Once enough traffic has been monitored across each variant and a clear winner has been determined, an A/B test can be terminated via a POST request to the ab-test/end endpoint. This endpoint accepts a JSON payload containing the abTestId of the target A/B test and the winnerId of the content deemed the winner.

In HubSpot, you can group together language variants of the same content. Learn more about working with multi-language pages in HubSpot. The following properties will be populated on pages within a multi-language group:

  • translatedFromId: unique identifier for the primary language page of the multi-language group. This property will be null on the primary page itself.
  • language: the ISO 639 code representing the language of the page.
  • translations: a map of ISO 639 codes to variant page objects within the multi-language group.

A new language variant of an existing page can be created via a POST request to the multi-language/create-language-variant endpoint. This endpoint accepts a JSON payload containing the id of the page to clone and the language identifier of the new variant.

A page can be added to an existing multi-language group via a POST request to the multi-language/attach-to-lang-group endpoint. This endpoint accepts a JSON payload containing the id of the target page, the language identifier of the page being added, and the primaryId of the page designated as the primary page in the target multi-language group.

A page can be removed from a multi-languages group via a POST request to the multi-language/detach-from-lang-group endpoint. This endpoint accepts a JSON payload containing the id of the target page.