Skip to main content
New Participant
July 21, 2026
Question

Asynchronous API call from interface and follow up API to get the status of the job.

  • July 21, 2026
  • 8 replies
  • 48 views

Hi

I have a requirement where I need to invoke an asynchronous API that returns a jobId in the response. After a certain wait time, I need to call a second API to check the status of the job by passing the jobId received from the first API. This status API should continue to be invoked at regular intervals until the job completes successfully.

All of these steps must be completed before the form is submitted, as activity chaining needs to be maintained.

Our current plan is to use a Start Process smart service to initiate the asynchronous operation and capture the process ID. I can then use Query Process Analytics at configurable refresh intervals to monitor the process status until the second API returns a successful response. Once the process completes, I can retrieve the results and display them to the user in a grid.

Is there any better approach than this /any drawback in this approach. Anyone had similar requirement? Please sugget.

8 replies

Participating Frequently
July 21, 2026

Hi [mention:2737f3edac9d496b9c0decdd18ead53e:e9ed411860ed4f2ba0265705b8793d05] 

Your approach is technically feasible, but the deciding factor is how long the external job typically takes.

If the job usually completes within a few seconds, I'd consider polling the status API directly from the interface (using a refresh variable or refresh interval) until the job completes or a timeout is reached. This avoids introducing another process model solely for polling.

If the external job can take longer (tens of seconds or minutes), then using a separate process model is more appropriate. However, I'd be cautious about relying on activity chaining for a long-running asynchronous operation, since activity chaining is intended for short-lived interactions and may not be reliable for extended polling.

Your proposed approach of starting a process and monitoring it via Query Process Analytics can work, but it does add complexity and requires handling retries, maximum wait times, failures, and process timeouts.

Out of curiosity, how long does the external job usually take to complete? That will largely determine the most suitable design.

New Participant
August 5, 2026

Hello khushim2808, 

I am facing a similar situation, my process runs for around 2 minutes.

As I understand the way to go is to start the process, write the process id into database and also write the data into db, once the job is completed.

The Interface will not query the process analytics, but only the database to display the current status and results.

correct? Are there any best practices docs for this kind of design?

Thanks in advance.

harshas2775
Brainy
August 5, 2026

Instead of Query process Analytics, querying from database table synced to an Appian Record type will be better approach. Using a!refreshVariable() you can refresh the data within UI at intervals and keep users posted with real-time status.

New Participant
August 5, 2026

One option I have done previously for async api calls is write it into a table.
So call the integration and add a unique identifier into the data such as a correlation id. When the response comes back you then match that up to the row in your table and mark it as processed. Then if you need to poll in your form you simply query the record in the db. Using this mechanism you can also put in exception paths such as timers so that the row is marked as errored if the result doesn’t come back within a defined length of time. Ideally the best plan is not to have users wait and simply let them fire and forget and only have them manage exceptions where it fails especially where the external job may take a longer period of time. If you can build your whole process async it tends to scale better.

mathieud0001
Brainy
August 5, 2026
New Participant
August 5, 2026

I was told to use that way (local vars to hold the state) if the external process takes seconds. If it takes minutes, the way via a database table is more preferred.

Thats why I asked here in the community, to clarify further.

New Participant
August 5, 2026

Thanks for the reply, and for the hint with exception handling to cleanup errornous processes.