Improving consistency in the term "archived" across APIs - CMS Pages, Landing Pages, and Blog post APIs updating
Consistency across our APIs ensures developers know what to expect and can gain efficiency from it. We identified that the CMS APIs were using the term archived
in a way that was different from the rest of the platform. We're correcting that.
What's happening
In the CMS Hub user interface Blog posts, Website Pages, and Landing Pages can be archived
- which means to hide them from view. This differs from the other APIs like the CRM objects APIs. In those APIs to archive
means to delete
.
The objects that represent individual pages/posts have these changes:
deletedAt
is renamed toarchivedAt
. (To avoid breaking existing integrations, we will temporarily continue returning deletedAt)archived
is being renamed toarchivedInDashboard
- which refers to hiding the page rather than deleting. (To avoid breaking existing integrations, we will temporarily continue returning archived)
If you have integrations that depend on or set the archived or deleted states for pages you will want to update those integrations to use the correct property. If your integration queries based on if a page is deleted you'll want to query against archived=true
. If you want to query for if a page is visually hidden in the dashboard you can use archivedInDashboard=true
.
When is this happening?
The APIs have already been updated to contain the new properties. The breaking part of the change (discontinuing support for deletedAt
and archived
) will happen on December 5th. This should give you time to review your integrations and update them ahead of time to prevent a confusing experience for users.
Have questions or comments? Ask in our developer community forums.