Fallback Strategy
In case of any unavailability in the webhook service, it is recommended to implement a fallback mechanism to ensure your application can still retrieve the process result within the expected response time.
How it works
The webhook is the primary result delivery mechanism. However, you should treat the following signals as additional triggers to actively fetch the result via GET /client/v1/process/{processId}:
| Signal | Channel | What it provides |
|---|---|---|
onFinish callback | SDK Web / WebMobile | End-of-journey signal — no result |
callbackUri redirect | All other channels | URL redirect only — no result |
Neither onFinish nor callbackUri delivers the process result directly. They are end-of-journey signals only. Your back-end is responsible for correlating the received id (or the redirect) with the processId previously stored, and then calling GetProcess to retrieve the actual outcome.
Recommended flow
Once an end-of-journey signal is received, your back-end should call GET /client/v1/process/{processId} and validate the result in the following order:
- Confirm
state = PROCESS_STATE_FINISHED - Evaluate the
resultfield and apply your business rules
This ensures that temporary webhook unavailability does not result in loss of process outcomes.