Skip to main content

I am hoping to have something clarified for me when it comes to returned meta data for the GET/v1/styles/:key endpoint.


The docs say this is the return structure:


{

  "status": Number,

  "error": Boolean,

  "meta": { 

     "key": String,

     "file_key": String,

     "node_id": String,

     "style_type": StyleType,

     "thumbnail_url": String,

     "name": String,

     "description": String,

     "updated_at": String,

     "created_at": String,

     "sort_position": String,

     "user": User, 

   }, 

}

Is it safe to assume that this meta.key should match the key that is passed into the endpoint argument? If not, what is the reason for the difference?

The interesting part about this is I have an example where I pass in a style key, it returns a different key value in the meta.key When I pass that same key from the return into the endpoint, the meta.key matches the request’s style key…

Got an update from Jake on Discord



jake — Today at 3:48 PM

ok. got to the bottom of this. i think this is something that may change in the future, but essentially, when a style is moved to a different file, we unpublish the style behind the scenes, and create a new style with a new key. any queries for the old style return the new style with the new key.

to answer your question, it should be the same, but in this specific case it behaves a bit differently




me — Today at 3:54 PM

Thank you for looking into this, is there a time when that connection between the unpublished and newly published ID will be severed?




jake — Today at 4:16 PM

you can rely on the ids in the way that you currently are!




me — Today at 4:16 PM

thanks so much




jake — Today at 4:16 PM

i actually misread internall comms about this. i dont think this is changing any time soon at all


Reply


Terms & ConditionsCookie settings