> ## 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. # Troubleshooting > Common issues with API references This page covers the common errors you might encounter when sending requests to the APIs. This is usually caused by the selected modules in the journey builder not having the needed credentials. In this case, you encounter a `201` status code that returns an empty collection of tasks. This happens even when you have modules in the journey builder. The response looks like this: ```json theme={null} { "status": "Completed", "instanceId": "Qs7Zj2p4LMWT3V8Ndu9k6BRa", "tasks": [] } ``` To confirm this, send a `POST` request to the `/journey/state/fetch` endpoint. You will receive a response showing the `GET_CREDENTIALS_ERROR`code. To resolve this, contact your GBG GO account manager to update the credentials for your modules. When you call the `/journey/state/fetch` endpoint and receive a "COMPLETED" status (rather than a credentials error), this means that the journey has been successfully finished. All tasks associated with this journey instance have been completed, and no further action is required. If you are a new user who attempts to log in to GBG GO with valid credentials but is immediately logged out, this might be because your organization hasn't been created in the system yet. The account exists, but without an associated organization the system cannot direct you to your dashboard. As a result, the system automatically logs you out. To resolve this, contact your GBG GO account manager for help troubleshooting the issue. In adaptive mode, the **Facematch Verification** module requires both face images to be submitted in the API payload. Submitting only one image causes the task to fail. #### Symptom When you run a journey in adaptive mode and reach the facematch verification task, the submit task data request returns a system error. The same journey completes successfully when executed in prefill mode. #### Cause The **Facematch Verification** module compares two face images against each other to produce a match decision. The module needs both images available before it can run: * `face1Image` is the selfie image captured during the journey. * `face2Image` is the anchor (reference) image that the selfie is compared against. In prefill mode, both images are supplied up front in `context.subject` when the journey starts, so the platform has everything it needs for facematch verification. In adaptive mode, task data is collected progressively as the journey executes. You're responsible for submitting both images together when the facematch verification task is presented. If only one of `face1Image` or `face2Image` is submitted, then the **Facematch Verification** module cannot perform the comparison and the task returns an error. #### Resolution When the **Facematch Verification** task is reached, submit `face1Image` (selfie) and `face2Image` (anchor) together in the API payload: ```json JSON theme={null} { "intent": "Complete", "instanceId": "", "taskId": "", "data": { "context": { "subject": { "biometrics": [ { "face1Image": "", "face2Image": "" } ] } } } } ``` #### Why this differs from prefill Prefill journeys front-load all subject data when the journey starts, so modules that depend on multiple inputs receive them before any task runs. Adaptive journeys collect data task-by-task, which means modules with multi-input dependencies, such as facematch verification must receive all required inputs in the API payload for that task. If a task errors in adaptive mode but works in prefill, check the module's reference page for the inputs that task expects. The Webhook module is a variant, so when the webhook fires, the journey technically hasn't completed yet. Calling `/journey/state/fetch` immediately after receiving the webhook can return a state that doesn't yet reflect journey completion. To handle this: * Implement a short delay before calling `/journey/state/fetch` after receiving the webhook. * Implement a retry mechanism on your `/journey/state/fetch` call to handle cases where the state isn't yet finalised. #### Symptom You start a journey that contains a Webhook module in prefill mode. Your webhook endpoint receives a POST as part of the journey execution, before the `instanceId` is returned to your system. Because this is the first time your system has seen this `instanceId`, it isn't tracking it, so the webhook gets dropped and you can't act on it or fetch the results. #### Cause In prefill mode, the `/journey/start` call is synchronous by default. The call only returns its response, including the `instanceId`, after every module in the journey has finished processing. The Webhook module runs inside the journey, as the last module before the journey completes. Its payload includes the `instanceId`: ```json JSON theme={null} { "webhookCreatedAt": "2026-05-08T14:04:16.479398891Z", "deliveryId": "5ac674f6e2be56490a6d626c01ca9b228c99a37465e9e67c8ca21ae07b28e294", "instanceId": "PiLMes-cSuYR8aHYgtVco07_", "message": "Customer verification completed" } ``` The webhook fires before the synchronous `/journey/start` call returns, so your application receives the webhook before it has the `instanceId` from the API response. The `instanceId` is in both places, but the webhook arrives first, so your system has nothing to match it against. #### Resolution Run journeys that contain a Webhook module in asynchronous mode. Add `"async": true` to the `config` object in the request context when you call `/journey/start`: ```bash cURL theme={null} curl --request POST \ --url https://eu.platform.go.gbgplc.com/captain/api/journey/start \ --header 'Authorization: Bearer your_access_token' \ --header 'Content-Type: application/json' \ --data '{ "resourceId": "your-journey-resourceID@2z5wz848", "context": { "config": { "async": true }, "subject": { "identity": { "firstName": "Jane", "lastNames": ["Doe"], "dateOfBirth": "1992-10-01" }, "documents": [], "biometrics": [] } } }' ``` In asynchronous mode, `/journey/start` returns the `instanceId` immediately and the journey processes in the background. Store the `instanceId`, then match the webhook against it when it arrives and call [`/journey/state/fetch`](/docs/go-v1/api-reference/endpoint/fetch-journey-state) to retrieve the result: 1. Call `/journey/start` with `"config": { "async": true }` and store the returned `instanceId`. 2. When the webhook arrives, look up the stored `instanceId` from the payload. 3. Call `/journey/state/fetch` for that `instanceId` to retrieve the final state. If the state isn't finalised yet, apply the short delay or retry described in "Webhook fires before the journey completes" above. #### Why this differs from synchronous prefill Synchronous prefill suits callers that want a single blocking request that returns the full result, with no webhook involved. When you add a Webhook module, the webhook fires from inside the journey before the synchronous response returns, so you receive the completion signal before the `instanceId`. Asynchronous mode gives you the `instanceId` up front, so the webhook becomes a signal you can act on. It also avoids client-side timeouts on long-running prefill journeys. For all execution modes, see [Step 2: Start a journey](/docs/go-v1/developer-integration/execute-customer-journeys/start-a-journey-step) and [How to use and configure a Webhook module](/docs/go-v1/guides/product-guides/webhook-module-guide). #### Symptom You submit a full street address in the PEPs and Sanctions request, but the screening results only appear to consider the subject's name, date of birth, and country. This leads to more false positive matches than expected, particularly in ongoing monitoring (OGM). #### Cause The PEPs and Sanctions screening service only uses **country** and **city (locality)** when matching an address. It does not use street-level detail. This is by design, the service compares submitted details against watchlist records, which themselves typically only hold country and city-level address data. You can see this in the available hit types. The most granular address-based match codes are `Full name, DOB, city and country matched` and `Full name, city and country matched`. There is no match type that includes street name or building number. For details, see the [PEPs and Sanctions module reference](/docs/go-v1/platform/modules/compliance-screening/peps-and-sanctions). The [input payload](/docs/go-v1/platform/modules/compliance-screening/peps-and-sanctions#input-payload) reflects this, the `currentAddress` object only accepts `locality` and `country`: ```json JSON theme={null} { "context": { "subject": { "identity": { "firstName": "", "lastNames": [""], "dateOfBirth": "", "currentAddress": { "locality": "", "country": "" } } } } } ``` #### Resolution To improve match accuracy and reduce false positives, always populate both `currentAddress.locality` (city or town) and `currentAddress.country` when they are available. Providing the city in addition to the country gives the screening service more identity elements to match against, which narrows results and lowers the false positive rate. Street-level fields are not used and do not need to be sent.