Blog ID expected long

Developer Support APIs & Integrations
,
1

Hello again, when using the blog-post content type for the Get data for Hubspot hosted content, it returns the blog post ID as the breakdown. We then pass those blog post IDs into the List blog posts endpoint to get the names of each of those blog posts. However, we just ran into an issue where one or more of the blog post IDs returned by the analytics endpoint has a hyphen in it and then the call to get the blog post name returns an error saying it expected a long. Am I supposed to remove the hyphen from the blog post ID myself or is there something else going on?

2

Hi, @Wes4.

Happy to help. To troubleshoot effectively, though, I’ll need a bit more information. Would you share:

1. The Hub ID of the account you’re pulling these blog post IDs from.

2. One or two example blog IDs with hyphens.

3. The List blog posts endpoint doesn’t accept individual blog IDs. Are you instead passing the hyphenated blog ID values to this endpoint?

3

Sure thing:

1. The Hub ID I’m currently using is 127518

2. A couple of the IDs are “591062-203027” and “591062-203026”. It appears they are all starting with “591062”.

3. No I am using the List blog posts endpoint and using the (undocumented) parameter “id__in”. It allows me to filter certain blog posts. It works for regular IDs but these hyphen ones cause a 400 response.

The request looks like this:

https://api.hubapi.com/content/api/v2/blog-posts?limit=300&offset=0&id__in=7433319117&id__in=7430136613&id__in=591062-203027&id__in=591062-203026

4

Hi, @Wes4.

Thank you for providing this information.

First and foremost, we do not support or guarantee the performance of undocumented query parameters.

I will ask the team for insight into your error and whether we can add support for the id__in parameter, but I can’t promise any particular outcome.

Apologies for the inconvenience. I appreciate your understanding.

5

@IsaacTakushi

It is understandable that you would not support undocumented parameters, however, the issue still remains. Why am I seeing these blog IDs with hyphens when I query that analytics endpoint?

When I query the blog post endpoint without using the undocumented parameter and just page through every blog post, those IDs are still not present.

6

Hi, I never got a reply to my last comment. Was hoping for more info on this.

To reiterate, even if I do not use the undocumented parameter, and just page through all results from the List blog posts endpoint, the IDs with hyphens in them do not show up. Even if I remove the hyphens, they are not in this list.

I know that deleted blog posts will not appear in the results but even if they were deleted, why do they have hyphens at all?

7

Hey, @Wes4.

Sincere apologies for dropping the ball on this thread… I completely missed your replies. Going forward, please be sure to tag me with @IsaacTakushi and your message will be much less likely to fall through the cracks.

I took a closer look and found the following:

  • The hyphenated “ID” is actually a legacy analytics_page_id which predates the current analytics system. It is combines the following values…
  • The591062 string corresponds to another analytics_page_id field as well as alegacy_tab_id which I had not previously encountered.
  • The strings which follow theanalytics_page_id orlegacy_tab_id correspond to legacy blog post ID (legacy_id) values. If you retrieve blog ID 1936716288 from this endpoint, for example, you will find the analytics_page_id is a hyphenated 591062-188883 . The legacy_id value is even visible in old blog post URLs like: https://info.gbiosciences.com/blog/bid/188883/what-are-the-detergents-commonly-used-in-proteomics.

I’ll pass this insight along to the team and find out whether we can rectify the legacy analytics and blog IDs with our “new” IDs.