Skip to main content

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.

Once your journey is fully configured, the next step is to publish it. Publishing a journey makes it available for use in different environments. GBG GO allows you to publish journeys in two environments:
OptionPurpose
PreviewAllows testing before going live. Generates a schema for API integration.
ProductionDeploys the journey live for real users. Once published, the journey cannot be edited directly.
Publishing to Preview allows the development team to test API calls and verify that the journey is functioning as expected.

​
Publish to Preview

Publishing to preview allows you to test your journey before making it live. To publish to Preview:
  1. Click Publish to Preview in the journey editor.
  2. A confirmation message appears: Delivery deployed successfully.
  3. Click on Dashboard to see:
    • Environment (Preview)
    • Version number
    • Resource ID
    • Last published date
    • Schema
  4. The schema for your journey is automatically generated.

​
Understanding the schema

The schema defines what information is required for the modules in your journey.
  • If a new module is added, new fields may be included in the schema.
  • If a field is already used, it will be shared between modules, for example, an address field used in multiple verification steps.
  • Developers can copy the schema and use it for API integration with Postman or other tools.
Ensure your journey is fully tested in Preview before publishing to Production. Any changes will require creating a new version.

​
Publish to Production

Once testing is complete, you can publish the journey to Production. This makes it available for real users. To publish to Production:
  1. Click the Actions list in the Dashboard.
  2. Select Publish to Production from the menu.
  3. Confirm the action in the dialog box by selecting the checkbox.
  4. Click Publish to production.
The journey is now live. You can now use the Resource ID and schema for API integration in your production environment.

​
Important considerations:

  • Once a journey is published to Production, it cannot be edited directly.
  • If changes are needed, you must create a new version of the journey.
  • You will have two journey Resource IDs and versions,one for Preview and one for Production. They will be used for API integration in the steps below.

​
What’s next?

After publishing, the journey is ready for integration with your system. Choose either of the following delivery methods, depending on your needs to lauch your journeys:

​
FAQ

GBG GO provides two separate environments:
  • Preview environment: A test environment where you can validate journeys before deploying them to production. Use this to test API calls, verify journey behaviour, and confirm that modules are configured correctly.
  • Production environment: The live environment where published journeys are used by real customers.
To publish a journey to the preview environment:
  1. Open your journey in the Journey builder.
  2. Click Publish to Preview.
  3. A confirmation message appears: “Delivery deployed successfully”.
  4. Click Dashboard, where you can see the environment label (Preview), version number, resource ID, last published date, and the auto-generated schema.
To access preview data in the Investigation portal:
  1. Navigate to Investigation.
  2. Click the Preview Environment tab.
The preview environment uses a separate resource ID from production. When testing your API integration, use the preview resource ID from the Dashboard. Once testing is complete, publish the journey to production to generate a production resource ID.
A resource ID identifies a specific published version of a journey. When you publish a journey in GBG GO, the system assigns it a resource ID. You include this ID in the journey start request to tell the API which journey to run. To always use the most recently published version, append @latest to the resource ID (for example, your-resource-id@latest). To pin your integration to a specific version, use the fixed resource ID without @latest.An instance ID identifies a single execution of that journey. When you start a journey, the API creates a journey instance and returns a unique instanceId in the response. You use this instance ID in subsequent API calls.