Skip to main content
By default, the /journey/state/fetch response returns the customer’s personal data. It’s in context.subject, and in the subject of each module’s step result. For example, a step result can contain the address that an address verification module verified. If your system doesn’t need that data back, then set excludePii to true when you start the journey. The journey runs the same checks on the same data, but the state response leaves out the fields that hold the customer’s personal data. You still get the journey status, the result, and each module’s outcome and advice.
Set excludePii to the JSON boolean true. The API accepts any other value, including the string "true", without an error, and then returns the personal data as usual.

When to exclude PII

Exclude PII when your system acts on the journey result, but doesn’t need GBG Go to send back the customer’s details. For example:
  • Your backend reads only the result and the module outcomes to decide whether to approve the customer.
  • You already hold the customer’s details, because your own interface collected them.
  • You want to reduce the personal data that reaches logs, queues or other systems that store the state response.
Don’t exclude PII if your system reads customer data from the state response. For example, to show the verified address, or to read extracted document data from a step result.

Before you begin

Make sure you have:
  • Published API journey: A journey published with API delivery. You need its resource ID and version.
  • Access token: Obtained in Step 1: Authenticate.

Start a journey without PII in the state

To exclude PII, set excludePii to true in context.config when you start the journey.
The start response is the same as for any other journey. Keep the instanceId for the calls that follow.
JSON

Request body fields

This field controls PII exclusion. For the other start request fields, see Step 2: Start a journey.

What the state response leaves out

When you fetch the journey state of a journey started with excludePii, the response leaves out these fields entirely. They aren’t returned as empty objects. excludePii also removes subjectSources, subjects, results and result.raw at the same levels. The response leaves these fields out even without excludePii. The response still includes:
  • The journey status and context.result, apart from the fields in the table.
  • Each step’s outcome, advice and process details.
  • The journey details in context.process.journey.
excludePii removes only the fields in the table. Personal data inside the fields that the response keeps can still appear. For example, result.error can contain provider text with names and dates of birth, and result.advice or module-specific result fields can contain nested personal data.Don’t treat the response as free of personal data. Apply your own controls before you log or store it.
A synchronous start response leaves the same fields out of its state. excludePii works the same way for journeys with page delivery.
excludePii changes only what the API returns. The journey’s modules still receive the customer’s data, and they return the same outcomes and advice as they would without it.

Example responses

Both of these responses are from the same journey, started with the same address and email. The journey has run an address verification module, and it’s waiting for the customer to submit more data.
For a description of each field, see Step 5: Fetch journey state.

Handle a response without PII

With excludePii, the fields in the table are missing from the response, not empty. Read them as optional, so that your code doesn’t fail when they aren’t there.

Best practices

  • Check that your code sends excludePii as a boolean. A string value such as "true" doesn’t exclude PII, and the API doesn’t return an error.
  • After you turn on excludePii, fetch the state of a test journey and check that context.subject isn’t in the response.
  • If you need the customer’s details after the journey, then use the copy that your own system collected.