API Response Mock
The exact payloads a client app receives for UG — rebuilt from the configuration in this studio. Hand these to the web / iOS / Android teams to stub against before the config ships.
Copy all JSON · Download .json — one bundle containing the journey config response plus the form config response for every step (12 forms), as
ug-retail_onboarding-web-api-mock.json. Download .zip — the same responses as separate files, one per config, in
ug-retail_onboarding-web-api-mock.zip: journey-config.json, forms/{formKey}.json ×12, lookups/*.json ×0, and a README.txt describing the contract. Journey config response
GET /journey-configs?countryCode=UG&journeyId=retail_onboarding&channel=web{
"countryCode": "UG",
"journeyId": "retail_onboarding",
"channel": "web",
"journeyVersion": 1,
"workflowConfig": {
"initiateAfterStepId": "basic_info",
"completeOnStepId": "confirm"
},
"steps": [
{
"stepId": "basic_info",
"type": "Form",
"formKey": "basic_info",
"formVersion": 1,
"title": "retail_onboarding.ug.step.basic_info.title",
"sequence": 1
},
{
"stepId": "ekyc",
"type": "Form",
"formKey": "ekyc",
"formVersion": 1,
"title": "retail_onboarding.ug.step.ekyc.title",
"sequence": 2
},
{
"stepId": "review_information",
"type": "ReviewForm",
"formKey": "review_information",
"formVersion": 1,
"title": "retail_onboarding.ug.step.review_information.title",
"sequence": 3
},
{
"stepId": "address",
"type": "Form",
"formKey": "address",
"formVersion": 1,
"title": "retail_onboarding.ug.step.address.title",
"sequence": 4
},
{
"stepId": "occupation",
"type": "Form",
"formKey": "occupation",
"formVersion": 1,
"title": "retail_onboarding.ug.step.occupation.title",
"sequence": 5
},
{
"stepId": "email",
"type": "Form",
"formKey": "email",
"formVersion": 1,
"title": "retail_onboarding.ug.step.email.title",
"sequence": 6
},
{
"stepId": "confirm",
"type": "ConfirmForm",
"formKey": "confirm",
"formVersion": 1,
"title": "retail_onboarding.ug.step.confirm.title",
"sequence": 7
}
],
"branches": [
{
"branchId": "fatca",
"triggerAfterStep": "address",
"resumeBeforeStep": "confirm",
"description": "retail_onboarding.ug.branch.fatca.description",
"triggerHint": null,
"steps": [
{
"stepId": "confidentiality_waiver",
"type": "ConsentForm",
"formKey": "confidentiality_waiver",
"formVersion": 1,
"title": "retail_onboarding.ug.branch.fatca.confidentiality_waiver.title",
"sequence": 1
},
{
"stepId": "fatca_tax_details",
"type": "Form",
"formKey": "fatca_tax_details",
"formVersion": 1,
"title": "retail_onboarding.ug.branch.fatca.fatca_tax_details.title",
"sequence": 2
},
{
"stepId": "fatca_documents",
"type": "Form",
"formKey": "fatca_documents",
"formVersion": 1,
"title": "retail_onboarding.ug.branch.fatca.fatca_documents.title",
"sequence": 3
}
]
},
{
"branchId": "crs",
"triggerAfterStep": "address",
"resumeBeforeStep": "confirm",
"description": "retail_onboarding.ug.branch.crs.description",
"triggerHint": null,
"steps": [
{
"stepId": "crs_declaration",
"type": "ConsentForm",
"formKey": "crs_declaration",
"formVersion": 1,
"title": "retail_onboarding.ug.branch.crs.crs_declaration.title",
"sequence": 1
},
{
"stepId": "crs_tax_details",
"type": "Form",
"formKey": "crs_tax_details",
"formVersion": 1,
"title": "retail_onboarding.ug.branch.crs.crs_tax_details.title",
"sequence": 2
}
]
}
]
}Form config responses
One per step, resolved as base form + UG overlays for web. Reaches the client embedded as form on the step response.
Lookup responses
Country data, not form config — the client calls these separately from the journey. Edit UG country data →
What the service does that this mock can't
- hash & context. The live form payload also carries a server-computed
hash(SHA-256 over the resolved schema + ui) and acontextdictionary. Both are computed at resolve time, so the mock omits them rather than inventing values — treat them as present-but-opaque. - Branch conditions stay server-side. A branch exposes only
triggerHintto clients; the realconditiontree and any stepexitRulesare evaluated by the backend and never serialized. - otpEnabled is internal.
workflowConfigreaches clients withinitiateAfterStepIdandcompleteOnStepIdonly. - Step types are PascalCase on the wire. Seed files say
REVIEW_FORM; the API emitsReviewForm. Nulls are serialized, not dropped. - Status pages carry no form. A
STATUS_PAGEstep binds a form so the service can validate what it fetches itself, but the client receivesform: null. The replies shown above are composed from the contract, not captured — what comes back depends on the upstream check, and the00reply also inlines the next step's resolved form undernextStep.