MessageId field in client payload guaranteed to match MessageId obtained after sending a message on the server?

[andynewman10]

Firebase returns an FCM message id when a message is sent on the server side if the operation was successful. This string is in the form:

projects/myproject-ffffff/messages/030aa08c-5e57-aaaa-bdbe-abcdeeeeffff

Notice the last part of the string. When the client receives the message, an fcmMessageId field is present in the payload on the web matching this last part. On mobile, a messageId is also available.

My question is: is it guaranteed that the client fcmMessageId/messageId will be identical to the last part of the MessageId string obtained on the server as a result of sending the message using the FCM API?

Based on my analysis, it looks like this is the case, but I do not see anything about this in the documentation and searching this forum yielded no result. I want to rely on this id for processing after a multicast send operation, so a guarantee is very important.

[barry166]

I would not treat that suffix match as a documented guarantee.

The server send API returns a message resource name, and the client SDK exposes an FCM message id, but the docs do not state a contract that the client fcmMessageId/messageId must always equal the last path segment of the server response string. It may match in practice, but relying on path parsing makes the app depend on an implementation detail.

For reliable multicast correlation, include your own id in the data payload, for example data: { correlationId }, and keep the server-side send result mapped to the token you sent to. Use FCM's message id for logging/debugging, not as the only application-level correlation key.