At any point during a journey, you can check the overall journey status and results. This is especially useful after the final interaction is submitted, when you need to detect completion and retrieve verification outcomes.Documentation Index
Fetch the complete documentation index at: https://docs.go.gbgplc.com/llms.txt
Use this file to discover all available pages before exploring further.
What you need
Before sending the request, make sure you have:- Access token: Obtained in Step 1: Authenticate.
- Instance ID: The
instanceIdreturned when you started the journey.
Fetch journey state
Send aPOST request to the /journey/state/fetch endpoint:
BASH
Request body fields
| Field | Required | Description |
|---|---|---|
instanceId | Yes | The journey instance ID returned when you started the journey. |
Journey pending response:
If the journey is still in progress, then the response contains:JSON
Journey completed response:
Once the journey completes, the system returns a response similar to the following:JSON
Response fields
| Field | Description |
|---|---|
instanceId | The journey instance identifier. |
status | Current journey status: InProgress, Completed, or Failed. |
context.process.journey.name | The name of the journey. |
context.process.journey.startedAt | The ISO 8601 timestamp of when the journey started. |
context.process.journey.id | The internal journey definition identifier. |
context.process.journey.version | The version of the journey that was started. |
context.process.instance.id | The journey instance identifier (matches instanceId). |
context.process.steps | Array of steps executed so far. Empty while the journey is in progress. |
context.subject | The identity data collected during the journey. Empty object until the journey completes. |
context.result.status | The verification result status: pending, completed, or failed. |
context.result.advice | The verification advice returned on completion. Empty object until the journey completes. |
Journey lifecycle states
| Status | Description |
|---|---|
InProgress | The journey is still in progress. Continue polling. |
Completed | The journey has finished successfully. Verification results are available. |
Failed | The journey encountered an unrecoverable error during execution. |
Polling for completion
Poll the state fetch endpoint at regular intervals until the journey completes:- Begin polling after submitting the final interaction data.
- Stop polling when
statuschanges toCompletedorFailed.
Recommended polling settings
| Setting | Value | Description |
|---|---|---|
| Base interval | 10s | Time between polling calls. |
| Error backoff | +5s | Add five seconds per consecutive error. |
| Max error retries | 30 | Stop polling after 30 consecutive failures. |
| Reset on success | Yes | Revert to base interval after a successful fetch. |
| Stop condition | Status | Stop when journey status is no longer InProgress. |
Best practices
- Do not share your access token with the frontend. All polling should be done from your backend server.
- Handle the
Failedstatus gracefully. Inspect the response for error details and determine whether the journey should be retried or escalated.
FAQ
What is the difference between sync and async journey execution?
What is the difference between sync and async journey execution?
In the v2 API, all journey execution is asynchronous. There is no synchronous mode.When you start a journey, the API returns an
instanceId immediately. Backend modules such as document verification, face matching, data checks process in the background.To track progress, you poll the /journey/interaction/fetch endpoint to discover when the next interaction is available, or poll /journey/state/fetch to check the overall journey status.The recommended polling approach is to call the fetch endpoint at a base interval of 10 seconds, apply backoff on errors, and stop when the journey status changes from InProgress to either Completed or Failed.If you are migrating from v1: the async: true flag was a v1-specific concept. In v2, async behaviour is the default and does not need to be specified.