Blogpost version endpoint response

[George Fraser]

I have defined blogpost version number and blog post id which is coming as nested json in blogpost version endpoint as a composite key. However I saw that blogpost is coming as nested json sometimes but sometimes page is coming as a nested json , but in the composite key I have defined blogpost Id as primary key along with blogpost version number. 
But whenever we are getting page as nested json instead of blogpost system is throwing null primary key error. 
Now my question is why page nested json is coming under blogpost version that too we are passing page blogpost id in the endpoint. So just got confused, whether I have to treat this id as blogpost Id or page id.
I also verified the particular id which is coming in page nested json inside blogpost version endpoint response using below curl 

curl --request GET \ --url 'https://{your-domain}/wiki/api/v2/pages/{id}' \ --user 'email@example.com:<api_token>' \ --header 'Accept: application/json'

But I ended up with 404 error, how ever same Id I have passed in below curl 

curl --request GET \ --url 'https://{your-domain}/wiki/api/v2/blogposts/{id}' \ --user 'email@example.com:<api_token>' \ --header 'Accept: application/json'

I am able to fetch the records.

So its clearly saying that the id's which are coming under nested json of blogpost or page in the blogpost version endpoints are only related to blogpost, if this is true why I am getting page nested json in the blogpost version endpoint.

Questions:
1. page nested json is expected in blogpost version ?
2. if above point is true should I treat the details of that page nested json as page details ?
3. If above point is true, why I am not able to fetch the details of particular Id in page endpoint and why its working in blogpost endpoint.

Blogpost version curl :
curl --request GET \ --url 'https://{your-domain}/wiki/api/v2/blogposts/{id}/versions' \ --user 'email@example.com:<api_token>' \ --header 'Accept: application/json'

Response screenshot for reference:

[Martin Runge]

Hi @George Fraser

From my understanding, the page reference showing up in some versions is almost always a content type conversion. If a page was later converted to a blog post, the older versions keep the page type, and the version where it flipped shows contentTypeModified as true. I would scan the version list for that flag to confirm.

Two things I would keep in mind:

• The id stays stable across a conversion page to blog post.
• The v2 API returns IDs to call separately, never full nested objects.

For your composite key, I recommend keeping the ID along with the version number, and removing the assumption that the ID always represents a blog post. Currently, it is a content ID that resolves as a blog post.

Is this still relevant, or did you already get it working?

Cheers,
Martin