Hi @keviny 

Your analysis on the logic of how this works on the backend is correct. 

With the receive custom messages endpoint, you will receive a response like the following:
{
  "status": "accepted",
  "message_uid": "1eab543f84a0785f7b6b8967cck18f4d"
}

Since the message creation process is happening asynchronously, you will not immediately see the Front conversation ID or message ID. However, you are provided the message UID in the response. With the UID, you can utilize resource aliases to identify the message data you are looking for within the API. See here: https://dev.frontapp.com/docs/resource-aliases-1#messages 

This would enable you to fetch messages with the UID as follows:
alt:uid:1eab543f84a0785f7b6b8967cck18f4d for the message with the uid 1eab543f84a0785f7b6b8967cck18f4d.

Let us know if you have any other questions! 

Best, 
Justin

Hi @justin, thanks for the response!

So basically we would need to retain the message_uid and call the messages API at later time to fetch the conversation id associated with that message? I tried calling the messages API with the alias immediately after “Receive custom messages” and it was returning a NOT FOUND. After waiting a bit more, then it returned data.

The second part of my original question was whether the process is also async with the https://dev.frontapp.com/reference/sync-inbound-message api? Or is there no way around the asynchronous nature of message/conversation creation?

Thanks again,

Kevin

Hi @keviny! 

Happy to shed some light on these questions:

I tried calling the messages API with the alias immediately after “Receive custom messages” and it was returning a NOT FOUND. After waiting a bit more, then it returned data.

Yes, this would be expected due to the asynchronous nature of the message creation. I would recommend having a delay setup on your end to fetch the message by UID after a given time to allow for processing and creation of the initial request. 

The second part of my original question was whether the process is also async with the https://dev.frontapp.com/reference/sync-inbound-message api? Or is there no way around the asynchronous nature of message/conversation creation?

By nature, it is still asynchronous. In the response with this endpoint, you will still receive UID as opposed to a Front conversation or message ID. In my testing the time to process is usually within a few seconds, although this could vary slightly by message complexity. I’m unsure just how quick of a turnaround your workflow for the requests are but with a bit of testing and implementing a standard delay to space out your requests should help provide the expected message info when fetching by UID. 

Best, 
Justin

Thanks for confirming @justin

Related to this question, is there any way to get the message_uid back from the messages in a conversation? I can call this https://dev.frontapp.com/reference/list-conversation-messages to get messages, but they only return the id and not the uid. I wanted to use it as a way to detect whether a pending message on our side has indeed been persisted on your side in a conversation when we fetch it without calling for each individual message. Another way I could potentially do this is is by checking the body of the message, but that may not be 100% reliable.

Hi @keviny! 

Good question. We only return the uid in responses for the aforementioned endpoints where a message is being asynchronously created. 

On the other hand, if a Front message ID is being returned, the message would not be pending and would be created and present within Front. Additionally, you may be able to configure a workaround with the body but that could be potentially unreliable as you mentioned. 

Best, 
Justin