Workiva Support Center

In dynamic integrations, especially when using HTTP connectors in automated workflows (such as Chains), it’s critical to handle the response from an API call effectively. Output Parameters allow users to capture essential pieces of data returned by the API — such as the response body, response headers, and status code — so that this data can be used in downstream steps.

What Problem does this solve?

Output parameters are crucial for creating responsive and intelligent workflows.

• Dynamic Workflows: Output parameters make it possible to tailor what happens next based on what the API returns — for example, extract a token, check if a record exists, or confirm a successful operation.
• Automation: By capturing values automatically, users avoid manual input or hard-coding, allowing workflows to scale with less maintenance.
• Streamlined Integrations: Connecting systems like authentication servers, CRMs, or custom APIs becomes more seamless because the connector adapts based on the data it receives.

Who does this affect?

• Developers and Integrators: Those building automation chains or integrations between systems.
• Data Analysts: Those who rely on real-time, accurate data flows to power dashboards or reporting.
• System Admins: Those who maintain and troubleshoot integrations — having access to output parameters helps pinpoint issues quickly.

What are Output Parameters?

The Output Parameters in an HTTP Connector are used to define the expected outputs of an HTTP request, such as response headers, response body, or response code. These define the expected results of an HTTP request, which can then be reused in subsequent nodes or logic steps in a chain.

Example Output Parameters:

• Response Headers: Metadata such as content type, server, or rate limit status.
• Response Body: The actual content returned by the API — typically in JSON or XML format.
• Response Code: Indicates success (200), client error (400), server error (500), etc.

Example: Capturing an Access Token

Suppose an API returns a token like this:

{
  "token_type": "Bearer",
  "expires_in": 600,
  "access_token": "<access_token_string>",
  "scope": "graph:write graph_api|r permissions|w ..."
}

You can define access_token as an output parameter, then pass it to the next step (e.g., to authenticate another API call).

Why is the Response Body needed?

The Response Body is typically where the API returns the most important information. These may include, but are not limited to:

• IDs of newly created records
• Authentication tokens
• Query results or data payloads

Without accessing the response body, you're limited to metadata, which restricts how dynamic your workflow can be. 

We can now get the access_token available under the Response dropdown.

Common Error Handling Scenarios

Typical issues you may encounter when working with Output Parameters:

• Error: undefined output parameter

  Cause & Fix: The response body structure has changed or is nested. Confirm the correct JSON path to the field.

• Error: 401 Unauthorized

  Cause & Fix: Token missing or expired. Ensure the token is captured and passed properly.

• Error: 500 Internal Server Error

  Cause & Fix: Server issue or invalid request payload. Check the response body for more context.

• Error: Invalid JSON

  Cause & Fix: The API returns a malformed response. Use a Try-Catch block or validate the output before parsing.

What is a Bearer Token and why is it needed?

A Bearer Token is a type of access token used in OAuth 2.0 authentication. It authorizes a user or application to access an API. It is called "Bearer" because you "bear" the token in the header of your HTTP request.

Example header:

Authorization: Bearer <access_token>

This token is more secure than basic authentication because:

• It expires, reducing the risk from token leaks.
• It can carry scopes and permissions.
• It separates authentication from authorization.

Why not just use Basic Authentication?

While Basic Auth sends a username and password encoded in each request, it:

• Is less secure — credentials can be reused or intercepted.
• Cannot easily expire or scope access.
• Lacks token-based permissions control.

Bearer tokens support token expiration, refresh, and granular permissions, which makes them a better choice for modern APIs and enterprise-grade security.