HTTP Complete Journey
(For backend API journeys only) Sends a custom HTTP response to the calling application, completing the journey.
Description
The HTTP Complete Journey step is a core component of Backend API Journeys, designed to finalize backend-to-backend workflows by generating a structured HTTP response. It is specifically tailored for responding to RESTful API calls, making it ideal for integrations requiring data processing, validation, or authentication.
This step allows you to define the response type and payload, including the HTTP status code and any additional data, to meet the specific requirements of the calling application. Common use cases include signaling success or failure and returning data for integration with external systems.
By default, the HTTP Complete Journey step is included in all journeys created using the Backend API (single call) journey type, ensuring seamless completion of backend workflows.
To learn more About backend API journeys, see our dedicated page.
Configuration
Field | Description |
---|---|
Response Code | The HTTP status code and description to return in the response (e.g., 200 OK for success or 400 Bad Request for error). Supports 2xx , 3xx , 4xx , and 5xx status codes with their descriptions. |
Redirect URI | The URI to include in the Location header for redirection responses (3xx ). For example, https://www.demoapp.com/login?error=auth_failed . |
Response Headers | Custom headers to include in the HTTP response, such as Cache-Control , X-Custom-Header , etc. |
Response Type | The format of the response body, which determines the Content-Type header. Supports text , json , and html . |
Body | The content of the response body. |
Example: Transaction validation journey
This example demonstrates how the HTTP Complete Journey step is used to respond to a backend API call that validates a transaction. The journey evaluates two conditions:
-
Access and ID token expiration
: Verifies the validity of the
external_access_token
provided by an external system. -
Multi-Factor Authentication (MFA)
: Checks whether MFA has been performed using the
amr
claim from theexternal_id_token
.
Journey logic flow
-
If the
external tokens
have expired, the journey rejects the transaction with a
401 Unauthorized
response. -
If MFA has not been performed, the journey triggers a client journey with a
307 Temporary Redirect
response. -
If both conditions are satisfied, the journey approves the transaction with a
200 OK
response.
HTTP Complete Journey step configurations
Below are the configurations for each HTTP Complete Journey step in this example:
Step | Description | Response Code | Redirect URI | Response Type |
---|---|---|---|---|
1 | Rejects the transaction due to expired external tokens | 401 Unauthorized |
||
2 | Approves the transaction | 200 OK |
||
3 | Triggers step-up authentication | 307 Temporary Redirect |
https://yourdemoapp.com/stepup |
text |
Backend API call example
To invoke the journey, use the following curl
command:
curl -X POST "https://api.transmitsecurity.io/ido/api/v2/invoke-api-journey/[JOURNEY_ID]?clientId=[CLIENT_ID]" \
--header "Content-Type: application/json" \
--header "Authorization: Bearer <[CLIENT_TOKEN]>" \
--data '{
"external_access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVC...",
"external_id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVC..."
}'
Note
The Authorization header must include a Mosaic client access token to validate the backend API call. For more details, see our Get Client Access Token API reference.