Implementing Get Status Polling

Ensure that:

The backend exposes a GET /status API that returns the standard status flags.
An asynchronous operation that triggers pricing and revalidation has been initiated.

Cart pricing and related operations are executed through an asynchronous backend process that includes multiple steps such as pricing, revalidation, and cart processing. Because these operations do not complete within the initial request–response cycle, the UI cannot know when pricing and revalidation have finished just from the action that triggered them.

To expose the progress of these asynchronous steps, the backend provides a GET /status API. This API returns a set of Boolean flags that describe the current state of pricing and cart processing. A simplified example response is:

{
  "IsPricingPending": false,
  "IsPriceProcessingPending": false,
  "IsPriceTotalingPending": false,
  "IsCartProcessingPending": false,
  "IsRevalidationNeeded": false,
  "IsApplyRevalidationPending": false,
  "IsCartFinalizationPending": true,
  "IsHardRevalidation": false,
  "IsCollaborationPending": false
}

The UI must poll the GET /status API at a regular interval (for example, every 0.5 seconds) and inspect these flags to determine when processing is complete. For the polling mechanism, the most important flags are:

IsPriceProcessingPending
IsApplyRevalidationPending

Polling continues while either of these flags is true, and stops when both become false, or when a timeout or error occurs. Once polling stops, the UI refreshes pricing and cart details for the affected lines. During polling, users can still navigate to the configuration page to update configuration or reprice any lines that are not part of the current polling request.

Start polling the Get Status API after initiating the asynchronous process.

Begin polling as soon as the UI triggers the operation that performs pricing, revalidation, or cart processing. For example, start polling after the user clicks a button that invokes an asynchronous pricing action.

Configure the polling interval (for example, every 0.5 seconds) based on your performance and UX requirements.
Call the Get Status API at the configured interval.
At each interval, send a GET /status request from the UI or integration layer.
```
GET /status HTTP/1.1
Host: <your-backend-host>
Authorization: Bearer <access_token>
```
Evaluate the IsPriceProcessingPending and IsApplyRevalidationPending flags in the response.
Parse the JSON response and inspect the following flags:
- IsPriceProcessingPending
- IsApplyRevalidationPending
Apply the following logic:
- If IsPriceProcessingPending = true or IsApplyRevalidationPending = true, continue polling.
- If both flags are false, treat pricing and apply revalidation as complete for the current request.
Stop polling when processing completes or a timeout or error occurs.
Stop polling in any of the following conditions:
- Both IsPriceProcessingPending and IsApplyRevalidationPending are false.
- A timeout threshold is reached.
- An error is returned from the Get Status API.
Refresh pricing and cart details for the affected lines when polling stops.

After polling stops because both flags are false, refresh pricing and cart details for the lines included in the current polling request.
Allow users to update configuration during polling.

While polling is in progress, allow users to navigate to the configuration page to update configuration or reprice lines that are not part of the current polling request.

Ensure that these changes are scoped so they do not interfere with the in-flight polling operation.

The UI accurately reflects pricing and cart-processing completion by polling the Get Status API and refreshing cart details when processing is complete.

Conga Product Documentation

Welcome to the new doc site. Some of your old bookmarks will no longer work. Please use the search bar to find your desired topic.

Implementing Get Status Polling

Footer Section

Explore