Async message creation

Forum|Forum|1 year ago
August 23, 2024
5 replies
440 views

We want to use channels to support facilitating messaging in our app. At first, it looks like custom channels could work pretty well. The only issue is that when a message is first created by the “Receive custom messages” endpoint, we can’t immediately follow up with a query to get the message and conversation id because the message creation is apparently asynchronous. That would make our implementation more complex because we would have to retain the body of the message on our side in order to play back what was sent by the user while we wait for the message to completely flow through Front’s system. Would this be any different if we used application channels instead of custom channels- is the message creation also async when using the “Sync inbound message” API? Thanks!

custom channels

Best answer by justin

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

justinAnswer

Fronteer

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

K

kevinyAuthor

Conversationalist

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

justin

Fronteer

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

K

kevinyAuthor

Conversationalist

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.

justin

Fronteer

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

Sign up

Use your Front credentials

Login to the community

Use your Front credentials