...
- Using the endpoint: availableMessages - Retrieve an array with an overview of all messages that are ready for retrieval, including sequence numbers
This endpoint allows end users to retrieve an overview of all messages ready to be downloaded, including their corresponding sequence numbers. This information can be used to retrieve the messages from their respective *retrieve endpoints. If desired, the messages can be pulled in chronological order, given by the sequence numbers. Each "retrieve" endpoint will have an optional parameter "sequenceNumber", that allows for an individual collection of the corresponding message(s). If that parameter is left empty all available messages are retrieved (according to the limit set in the parameters). - Using the endpoint: availableMessagesAll - Retrieve an array of all the messages that are ready for retrieval, including message content (OPTIONAL, MAY NOT BE IMPLEMENTED)
This endpoint allows end users to retrieve an array of all messages ready to be downloaded, including their content. This would allow a registry to call one single endpoint to collect all messages.
Limitations:
This option does not work for all applications/tooling, like defining custom API connectors in the 365 PowerPlatform. In those cases the same static structure for all call responses on a specific endpoint is not only implementing best practices (IBP), but also required.
2. Pulling available messages from corresponding "retrieve" endpoints
After identifying which specific message(s) should be retrieved by using the availableMessages endpoint, the messages can be retrieved from the "retrieve" endpoints that correspond to the message type. In the request body, users can specify parameters such as the limit (number of messages to retrieve), "shouldPeek" and sequenceNumber.
Calling to a "retrieve" endpoint results in the retrieval of the requested messages. Users can process and display these messages in their application based on their type and content.
This pull model allows users to have control over the message type they retrieve, specifying limits and retrieving messages from a particular point in the sequence using "sequenceNumber"
3. Messages are (soft)deleted after retrieval
After retrieval messages are soft-deleted. This means that after retrieval, messages are marked as deleted for the end-user and no longer available in the "availableMessages" and their corresponding "Retrieve" endpoint.
After soft-deletion, messages will be stored for an additional temporary period of 72 hours. During this timeframe, the data is still restorable.
4. Restoring messages using the "recoverMessages" endpoint
To recover or "restore" a soft-deleted message, users can call to the "recoverMessages" endpoint. This endpoint allows users to bring back messages that were soft-deleted within a 72 hour timeframe.
This approach provides an additional safety measure for end users. In case a message was mistakenly deleted during the retrieval process, or if there is a need to recover soft-deleted data, this mechanism allows for data recovery without permanent loss.
Users should be aware that the functionality to restore messages is limited to 72 hours. After this window, the soft-deleted messages are permanently removed from the system. Also see: Chapter 2.4.7 Message storage retention policies.
...
The automatically generated Swagger (https://matchconnect-webconnect-api.azurewebsiteswmda.netinfo/swagger/index.html) reflects the implementation of the API endpoints in its current state with accurate details on the sub-schemas. This representation ensures that implementers have access to the most up-to-date information.
...