Hi @Bárbara Farias !

It sounds like you have a pretty customized setup here so it’s hard to say exactly what solution will work for your particular setup. However, when a conversation_part is created from a button in a Workflow, the part_type is “comment”. This does store the value of the button in the conversation_parts ‘body’ attribute. I think the issue here might be that you are using ‘quick_reply’ as your part-type. Are you able to achieve what your looking to do with a different part_type?

He, Jacob!
Thanks for the reply.

I can not use part_type as comment because in this case we are sending buttons to the visitor. That needs to be done by “quick_reply”. 
I think that either it’s a bug on the API or something is misleading in the documentation. Currently sending the UUID in the reply_options has no meaning since I can not get it back at any point when the visitor clicks on that button.

Here is the schema for an admin reply that contains reply options that mentions the UUID being send to metadata response:

And here is the example of the response on a user reply stated in the documentation:

Notice that the metadata for the conversation_part exists although is empty. That’s supposed to have the UUID in this property but I don’t receive any metadata back.

Is there any way I can force this info to be here? By the way I’m using the unstable version...

Hey @Bárbara Farias

If you retrieve the conversation by using the Unstable version of the API, you will get the UUID in the response. If you are not getting the UUID, it means you are not using the Unstable version while making the retrieve conversation call.

Here is an example, when I retrieve the same conversation while I am not on unstable, the UUID is not returned.

Whereas, if I switch to unstable version, the uuid will return in the response like the below.

As quick replies are only available on the Unstable version, you need to make sure you use that version while retrieving the conversation data.

Hope this helps! Let us know how it goes on your end 

Hey @aykut.aydin
Oh I see! thank you for the info…

In this case I’m actually receiving the conversation data via webhook, listening to ”conversation.user.replied” topic. This is where I would also expect to receive the metadata and where I can not get it.

Do you know something about the data sent via webhook?

@aykut.aydin Thanks a LOT!!!

I finally made it work. You were right although I was using the API version correctly, my APP was not using the unstable version so the webhooks were not up to date. Changed that and I could finally get the metadata for quick_reply_option_uuid.

Thank you so much! 

Glad to hear it @Bárbara Farias! Thanks for letting me know.

Yes, for anyone else viewing this thread, Webhooks send a notification to your endpoint based on which version of API you are using on your app. So either changing your current app’s API version or creating a separate app with Unstable version and receive the webhooks from that app will do the trick. This can be done on Developer Hub.