Improving consistency in the term "archived" across APIs - CMS Pages, Landing Pages, and Blog post A

Developer Support Developer Announcements
,
1

The original Developer Changelog announcement. The article content is copied from that post below for convenience. If you have questions or comments you can leave them below.
-----

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 to archivedAt. (To avoid breaking existing integrations, we will temporarily continue returning deletedAt)
  • archived is being renamed to archivedInDashboard - 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 below.

2

@jmclaren if I’m understanding this change correctly, this seems to be moving in the wrong direction. The CRM objects API doesn’t make sense because there is a need for both “archive” and “delete” as distinct functionalities, so rather than conflating the term “archive” to actually mean “delete”, the capability for each should be built into the platform.

Currently, if an object, like a deal, is “deleted” via the front-end UI, that object is only retained for 90 days and is accessible only within that 90 day window using the “archived” parameter in the GET endpoint. While that object could be considered archived, it is only for 90 days and then it is permanently removed, i.e. deleted, so the use of “archived” in the API is improper. Hubspot needs to incorporate both types of functionality: “delete” which should mean to permanently erase all existence of the object in the database; and, “archive” which should mean to remove from view in the front-end but still retain the record in the database for either recovery or data analysis.