Before
A principal flow would need to request a bearer token, use it to create an API work-session, and manually renew the session when needed. Someone would then need to copy the returned authentication values into the headers of subsequent requests.
How it works
- Receive an authentication request through the secure webhook and submit the configured credentials to obtain a bearer token.
- Use the bearer token to create an API work-session, with the sequence stopping if authentication fails.
- Return the bearer token and API token to the principal flow so it can continue with authorized requests.
Workflow details
- Webhook trigger: A TLS-only webhook starts the flow when a principal flow requests authentication credentials for Checkpoint Harmony Endpoint.
- Bearer token acquisition: The workflow submits the configured client ID and access key to obtain a bearer token from the authentication service.
- Work-session creation: It uses the bearer token to create a new API work-session, stopping the sequence if the authentication request or session creation fails.
- Credential handoff: After successful authentication, the flow packages the bearer token and API token in a webhook response for the principal flow.
- Operational result: The calling flow receives the credentials needed to populate request headers and continue with subsequent Checkpoint Harmony Endpoint API operations without manually renewing the session.
What changed
Authentication and session creation now occur automatically when a principal flow sends a webhook request, and the resulting tokens are returned directly to that flow for downstream API calls.
Work removed
Manually requesting a bearer token, creating and renewing an API work-session, and copying both returned tokens into subsequent request headers.
Expected outcome
Each invocation automates two authentication-stage requests and removes the recurring token-copying handoff, providing credentials to the calling flow in one response.
