Flowable HTTP task for REST service calls

Flowable HTTP task for REST service calls: when the Http task fits

When a process needs data from a REST service, or must trigger one, the Flowable Http task is the built-in option. The Http task makes HTTP requests from a process through a configurable HTTP client, so the call sits in the BPMN model itself rather than in a separate class. Its settings, such as connectTimeout and socketTimeout, are set on an HttpClientConfig bean, and the Flowable docs state that default settings apply when none are configured. Confirm those defaults against the BPMN constructs documentation for your Flowable version before you rely on them, because a default timeout that is too long can hold a process thread while a remote service is slow or down.

Use the Http task when the call is simple and stable: one endpoint, a clear request and response shape, and logic that needs no code beyond mapping values into process variables. Reviewers should check which HTTP methods the docs list as supported for the version in use, and whether the target API needs headers, certificates or custom token handling that the task configuration can express. The task is a good fit when a process model is the natural place to read the contract, and when the team wants the integration visible to analysts reviewing the diagram.

A Java delegate is the better choice when the call needs retry logic, pagination, multi-step orchestration, custom error classification or complex transformation that the model would hide in expressions. An external worker is better when the service is owned by a team that works in another language, when the call must be scaled or retried independently of the engine, or when outbound traffic should run outside the engine's transaction. Decide this before the first model is built, because moving a call from the model into code later changes the deployed process definitions and the tests that cover them.

What you need before building an Http task

An Http task is only as dependable as the platform, contract, network path and credentials behind it. Confirm these five items before you draw the first service task in a BPMN model, because each one changes how the task is configured and tested.

Flowable engine and Spring Boot baseline

Confirm which Flowable line you run before you add the HTTP client configuration. Flowable 8.0.0 was released on February 27, 2026 and moves to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. Flowable 7.x runs on Spring Boot 3 and Jakarta EE, so the HttpClientConfig bean and its dependencies must match the baseline your application already uses. Check the Jackson version as well, since 8.0.0 defaults to Jackson 3.

Target service contract

Get the REST API's published contract, including paths, methods, request and response schemas, status codes and error bodies, before modeling the call. The process variables you map into the request and out of the response are only as stable as this contract. Ask the service owner which versions are supported, how breaking changes are announced, and whether a test double or sandbox exists for the process team to exercise the task without touching production data.

Environment endpoints and configuration

Decide how each environment resolves the target URL, so the same BPMN model deploys to development, test and production without edits. Keep base addresses, timeouts and credentials out of the diagram and in externalized configuration managed by your platform team. Confirm that every environment has its own endpoint, and that a process deployed to test cannot call a production system by mistake.

Outbound network and certificate trust

Map which network segments, proxies and egress rules the Flowable runtime must cross to reach the service. Confirm that the JVM trusts the certificate authority that signed the service certificate, including any internal CA, and that the trust store is updated through your normal change process. Test the path from the same node and container image that runs the engine, since firewall rules often differ between build agents, developer machines and production nodes.

Named owner for each service account

Assign one accountable person to every credential the Http task will use. That owner approves the scope of the account, sets the rotation schedule, and responds when the account is locked or expires. Avoid a shared account used by several processes, because a single failure then stops unrelated work and makes audit trails hard to read. Record the owner in your service inventory alongside the process definitions that depend on it.

How to configure the Http task and its client

This sequence takes a team from an empty Flowable setup to a BPMN model that calls a REST service, maps the response into process variables and behaves predictably when the service is slow or unavailable. Each step ends with a check so the team knows the client is configured before moving on.

Define the HttpClientConfig bean
A Spring or Java developer adds an HttpClientConfig bean to the application configuration and sets connectTimeout and socketTimeout explicitly. The Flowable docs say the Http task uses this configurable HTTP client and falls back to default settings when none are configured, so an explicit bean makes the timeouts a deliberate decision that the team can review. Confirm the property names and any other settings against the version of the Flowable docs you are running. The step is done when the application starts and the bean appears in the application context with the values you set.
Agree timeout values with the service owner
Before the timeouts are fixed, the process owner and the owner of the called service agree on how long a call may wait to connect and how long it may wait for a response. These values should reflect the service's documented latency and the process's tolerance for delay, not the framework default. Record the agreed values in the configuration and in the design notes for the process. The step is done when the values are written down with the name of the service owner who approved them.
Add the Http task to the BPMN model
A process modeler places an Http task in the BPMN model and sets the HTTP method, the target URL and the request body. Where the URL or body depends on process data, use expressions that read process variables so the call reflects the current instance. Keep URLs and any host names in configuration where possible so the same model can move between test and production environments. The step is done when the model validates in the modeling tool and the task shows the method, URL and body you intended.
Map the request and response variables
The developer defines which process variables feed the request and where the response is stored, such as a status code, a response body or a selected field. Map only the data the next step needs, and avoid copying whole payloads into variables when they will not be used. Document the mapping next to the model so that later changes to the service contract are easy to trace. The step is done when a test run leaves the expected variables populated on the process instance after the task completes.
Define the error path for failed calls
The modeler adds an error path that the process follows when the call fails, such as a timeout, a connection refusal or an unexpected status code. Decide whether the process retries, waits for a corrective event or routes to a person, and make sure the path is reachable from the Http task. Confirm with your operations team how failed jobs are surfaced and retried in your environment. The step is done when a deliberately failing call takes the error path and leaves the instance in the state you designed.
Deploy the process to a test environment
The team deploys the process definition and the HttpClientConfig to a test environment that mirrors the production network path to the called service. The deployment should use the same configuration mechanism as production so that the timeout values are not silently changed. Start a process instance with representative input data. The step is done when the deployment succeeds and the instance reaches the Http task without configuration errors in the logs.
Verify response mapping and timeout behavior
A tester runs three cases: a normal response, a response slower than the configured socketTimeout and an unreachable endpoint or refused connection. For each case, the tester checks the mapped variables, the path the instance takes and the logged error. Compare the observed timeout with the configured value, because the actual cutoff can differ from the setting if other layers also enforce limits. The step is done when all three cases behave as the design says and the results are recorded for the release review.

How the Http task moves data between the process and the service

The Http task sends a request from a running process instance to a REST endpoint, waits for the response, and writes the result back into process variables before the engine moves on to the next flow element. The engine builds the request from the task's configured method, URL, headers and body expressions, resolving each expression against the variables in scope at that point in the flow. The call itself is made through the HTTP client the engine is configured to use. The Flowable docs say that client is configured through an HttpClientConfig bean, where settings such as connectTimeout and socketTimeout are set, and that default settings apply when no such bean is provided. That means the timeouts and any connection behavior your service depends on are decided in the engine's configuration, not in the BPMN model, so a reviewer who only reads the diagram will miss them. Confirm the default values and the exact configuration keys in the Flowable documentation for the version you run before you rely on any of them.

Because the engine thread waits on the outbound call, a slow or unreachable service holds that work for as long as the timeouts allow. The timeout settings therefore control how long a transaction and a thread are tied up, and the process model should be designed with that in mind. Where a call sits inside a transaction boundary, decide whether a failed request should roll back the work before it or be handled as a modeled error path. Retries are a separate decision. Confirm with the Flowable docs whether the Http task retries on its own, whether retries come from the asynchronous job executor after a failure, and how many attempts are made by default. Map each of these behaviors to a documented setting so the team knows which layer decides when a call is repeated.

Response handling follows the same pattern in reverse. The response body, status and selected headers are written to process variables through the task's output mapping, and any non-success status should be checked by a gateway or error event before the next service call uses that data. Plan the variable names and types up front, since a mismatch surfaces at runtime rather than at deployment. Run a test against a stub service that returns slow responses, error codes and malformed bodies, and confirm in the job and history tables what the engine recorded for each attempt.

Mapping request and response data into process variables

This table maps each HTTP request and response part to the process variable that carries it, with type, nullability and logging guidance. Use it as a checklist when you define input and output mappings on the Http task, and confirm each field against the exact Flowable version you deploy.

Field	Process variable pattern	Type and nullability	Logging guidance
Request URL parameters	Built from a variable such as customerId in the URL expression	String, required; fail the step if null	Log only the endpoint template, not resolved values with identifiers
Request headers	Non-secret headers such as Accept or Content-Type set from a constant or variable	String, required when the API demands it	Log header names; never log Authorization or API key values
Authorization credentials	Injected from a secret store or client configuration, not a process variable	String, required for protected APIs	Never store in a process variable, history or log, because history retains variable values
Request body	Serialized from a JSON-shaped variable such as orderPayload	Object or string, required for POST and PUT	Restrict to needed fields; avoid logging personal or payment data
Response status code	Mapped to a numeric variable such as httpStatus	Integer, always present after a completed call	Safe to log; use it to route error handling
Response body	Mapped to a variable such as serviceResult	Object or string, nullable on empty bodies and errors	Treat as sensitive by default; log only the fields your audit needs
Response headers	Selected headers mapped to variables such as requestId	String, nullable when the header is absent	Log correlation IDs; avoid cookies and set-cookie values

Handling timeouts, error responses and failed calls

A REST call from a BPMN model can fail in several distinct ways, and each failure needs its own branch in the process. The cards below cover the failure categories, how to route them with boundary events and gateways, and when a failed call should retry through the job system or wait for a person to decide.

Connection and socket timeouts

A connect timeout means the service never accepted the connection, while a socket timeout means it accepted the request and stopped responding. The two need different handling because a socket timeout can leave the downstream action half done. Set both values explicitly on the HttpClientConfig bean rather than relying on defaults, and confirm the values with the owners of the target service. Check that the process timeout you model on the task is longer than the HTTP settings, so the engine does not cut off a call the client is still handling.

Non-success HTTP status codes

A 4xx response usually means the request itself is wrong, such as a rejected payload or missing authorization, and retrying it unchanged rarely helps. A 5xx response often signals a temporary fault on the provider side. Decide per status family which branch the model takes, and record the status code and response body in a process variable so operators can see why the branch was chosen. Agree with the API owner which codes mean retry, which mean correct the input and which mean stop.

Malformed or unexpected responses

A call can return 200 with a body that is missing a field, has a changed structure, or is not JSON at all. The Http task will not validate business meaning for you, so a mapping step after the call should check required fields before any gateway uses them. Route structurally invalid responses to an error path rather than letting a null value flow into a decision. Keep a copy of the raw body for a limited time so support teams can compare it with the provider's contract.

Downstream outages

When a provider is down for an extended period, repeated retries across many process instances add load to a service that is already failing and fill the job queue with work that cannot succeed. Use a boundary timer to stop waiting, park the instance on a wait state, and resume it when the service recovers. Confirm with the service owner how outages are announced, and decide who can trigger a bulk resume once the provider is healthy.

Asynchronous retries for transient failures

Mark the Http task as asynchronous when a transient failure should be retried by the job executor rather than failing the instance or blocking a request thread. The async executor records retry state on the job, so a failed attempt is picked up again later, potentially on another node. Retry only failures that are plausibly temporary, and make sure the downstream call is idempotent or carries a request key, since a retry after a timeout may repeat a side effect that already happened.

Escalating to a human task

Some failures need a decision rather than another attempt, such as a rejected payment that requires a corrected account number or a call that is unsafe to repeat. Route these to a user task with the error details, the original request and the available actions as variables. Define who owns the queue, the expected response time and what happens if no one acts. Keep the human path separate from automated retries so an operator is never asked to approve a call that the job system is still retrying.

Http task, Java delegate or external worker: choosing the call pattern

When the service has a stable, documented contract, responds quickly and needs only standard headers or a basic credential, the Http task keeps the integration inside the model. Process analysts can see the endpoint, method and mapping in one place, and the call is configured through the process definition and an HttpClientConfig bean rather than through separate application code. This pattern suits lookups, status checks and notifications where a failed call maps to a clear retry or an error path.

Visible contract: the endpoint, method and variable mapping sit in the BPMN model, so reviewers can trace the call without reading Java.
Shared client settings: connect and socket timeouts are set once on the client configuration, which keeps behavior consistent across models.
Limited logic: response handling relies on mappings, so anything needing branching or transformation pushes complexity back into the model.
Synchronous waiting: the engine thread waits for the response, so slow services hold work that the timeout settings must bound.
Lower build effort: no separate deployable or worker service is needed for a single call.

Before choosing this pattern, confirm the service's timeout and error behavior with its owners and test the configured timeouts against that behavior.

Common Http task failures and how to fix them

This table pairs each common Http task failure with its likely cause, the check to run and the fix. Read it from the symptom in the first column, then work down the checks before changing the model or the client configuration. Most failures trace back to the HTTP client settings, the variable mapping or the credential source rather than the remote service itself.

Failure	Likely cause	Check and fix
Timeout with no request reaching the service	Connect or socket timeout on the HttpClientConfig bean is shorter than the network path needs, or the default settings apply because no config bean was registered	Confirm the HttpClientConfig bean is loaded and check the connectTimeout and socketTimeout values. Test the same URL from the engine host with curl, then raise the timeouts to match the service's measured response time
Task completes but process variables are empty	The response mapping points at the wrong JSON path or result variable, or the response body is empty while the status was success	Log the raw response body for one instance and compare it with the mapping expression. Fix the mapping, and make the next gateway or condition check the variable exists before it reads it
Certificate trust error on the outbound call	The service uses a certificate issued by an internal CA that is missing from the JVM truststore, or the hostname does not match the certificate	Check the exception for the failing chain and verify the CA with openssl from the engine host. Import the internal CA into the truststore used by the JVM running the engine, and do not disable verification
401 or 403 after a token was working	The access token expired, was cached past its lifetime, or the client credentials were rotated without updating the engine's secret source	Decode the token expiry and compare it with the failing timestamp. Refresh tokens before expiry through a token call in the model or a service, and confirm the secret store entry is the current one
415 or 400 from the service	The request is sent with a content type or body encoding the service does not accept, such as form data where JSON is expected	Inspect the outgoing request headers and body in a test environment. Set the Content-Type and body mapping explicitly in the task so the request matches the service's API contract
Intermittent 5xx errors and duplicate side effects	The task retries or the instance re-runs after a failure, and the service receives the same non-idempotent request more than once	Check the service's idempotency support and the failure path in the model. Send a stable request identifier and route repeated failures to a handling step instead of resending blindly
Connection refused or DNS failure	The engine host cannot reach the target through the network path, proxy or name resolution used in production	Run name resolution and a connection test from the same container or host that runs the engine. Confirm egress rules and proxy settings with the network team

Questions teams ask before building Http task integrations

What drives the cost of building Flowable Http task integrations?

The main driver is how many distinct REST endpoints the process calls and how much each one differs. Each endpoint needs its own request mapping, response mapping into process variables, and error branches, so cost grows with the count and variety of calls rather than with the BPMN diagram size. Authentication adds effort when each service uses a different scheme, such as API keys, OAuth2 client credentials or mutual TLS. Test coverage for success, timeout and failure paths is often the largest single item. Ask any quote to list endpoints, auth methods, error branches and test expectations separately, so you can see what is one-time build work and what recurs as services change.

Can our in-house team build Http task calls without a partner?

Yes, if your team already runs Java and Spring services and can read BPMN 2.0 models. The Http task itself is configured in the model and uses an HTTP client that you configure as a bean, so the build is mostly configuration, mapping and tests rather than new platform code. A partner adds value when the team has not operated Flowable before, when several services need consistent error and credential handling, or when deadlines are tight. Check your capacity for the security review of outbound credentials and for ongoing maintenance when partner-supplied models change. The Flowable docs on BPMN constructs are the starting point for the team's evaluation.

How long does an Http task integration take to build?

No duration can be given from the platform alone, because it depends on the scope. The main factors are the number of endpoints, whether the target APIs are documented and stable, how many authentication methods are involved, and whether test environments exist for each service. Delays usually come from waiting on service owners for API contracts, test credentials and firewall or network changes, not from the Flowable configuration. Ask for a schedule that lists these dependencies and who owns each one, so the timeline reflects what your organization must provide.

What do service owners and the security team need to provide?

Service owners need to supply API specifications, expected request and response shapes, error codes and their meanings, rate limits, and a test environment with non-production credentials. The security team needs to approve the outbound network paths, the credential storage approach for calls made from the engine, and the logging rules for request and response bodies, which may contain personal data. Agree early who may change a remote contract and how the process model is updated when that happens. Without these inputs, mapping and error handling usually have to be redone.

What should we check about timeouts and failed calls?

Confirm that every Http task has explicit connection and socket timeouts set on the HttpClientConfig bean, rather than relying on defaults that you have not reviewed. Decide which HTTP status codes and timeouts should route to an error boundary, which should retry through the job executor, and which should fail the instance for operator review. Check how retries interact with non-idempotent calls, such as payments or record creation, because a retried POST can duplicate work. Test each branch with a stub service that returns slow responses, server errors and malformed bodies.

How should outbound credentials for REST calls be stored and rotated?

Do not place API keys, passwords or client secrets directly in the BPMN model or in process variables that appear in history. Store them in a secrets manager or in an externally managed configuration source that the Spring application reads at runtime, and reference them by name. Restrict which process definitions can use each credential, rotate them on a schedule your security team sets, and confirm that logs and history do not record the Authorization header. Ask your security team to review the design, since DeployOpen does not issue security certifications or attestations for the result.

What does a fixed-scope quote for Http task work need to include?

Send a written scope that lists each REST endpoint, its method and purpose, the authentication scheme, the request and response fields that map to process variables, the error branches expected, the test cases and environments, and the documentation and handover deliverables. Identify what your team provides and by when. DeployOpen plans most engagements as fixed scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, so the more precisely the endpoints and dependencies are described, the more precise the quote will be. Ongoing support and upgrades can be handled separately as a retainer.

How DeployOpen works on this

DeployOpen plans and delivers Flowable HTTP task integrations as part of self-hosted Flowable work in infrastructure you control. Each engagement starts with a written scope that names the REST services, the process variables they touch and the failure behavior the process must handle.

How we scope

Inventory every REST endpoint a BPMN model will call, with methods, payload sizes and expected response codes.
Agree timeout values, retry expectations and the business behavior for each failure outcome before any model is built.
Record which outbound credentials are needed, who owns them and where they will be stored.

How we build

Configure the HttpClientConfig bean with agreed connection and socket timeouts instead of relying on defaults.
Map request and response fields into process variables using documented expressions, with a written variable contract per task.
Test success, timeout, error status and malformed response paths in the engine before deployment to shared environments.

How we hand over

Deliver the process models, configuration, test cases and an integration register listing each external call and its owner.
Document the credential rotation steps and the runbook for diagnosing failed HTTP tasks in the engine.
Walk your platform and integration teams through the failure handling so they can change endpoints safely.

How we support

Fixed-scope engagements have written deliverables and timelines agreed before work starts.
Ongoing support, upgrades and continuous testing for Flowable integrations are available as a retainer.
Confirm with your team which parts of the integration, such as endpoint changes or new services, fall under a retainer scope.

Flowable HTTP task for REST service calls