Making Direct API Calls with Workato HTTP tool

What You'll Learn

By the end of this article, you'll know when to go beyond the built-in PlanRadar connector and call the API directly using the HTTP tool, how to configure requests and parse responses and how to keep your response schema up to date.

Pre-requisites

Readers should be familiar with REST API concepts and using the HTTP protocol to send requests.

When to Use the HTTP Tool

The PlanRadar connector in PRC provides pre-built actions for common operations. However, some scenarios require bypassing the connector and calling the PlanRadar API directly using the Workato HTTP tool:

• You need to perform actions that the PlanRadar connector does not currently support.

• You need to update tickets dynamically across multiple projects. The connector's Update Ticket action works within a single selected project. For cross-project updates where the project is determined at runtime, direct API calls are necessary.

Connecting the HTTP tool by Workato

To connect the HTTP tool by Workato to your PlanRadar account:

1. Navigate to Connections and search for HTTP and select it

2. On the connection setting page, choose a suitable name and location

3. Choose header Auth as the authentication type

4. Show and add new headers as:

   1. Key = X-PlanRadar-API-Key

   2. Value = Your personal access token

5. Set Base URL as your region specific URL (e.g. https://www.planradar.com/ )

6. Press Connect

Configuring an HTTP Request

When using the HTTP tool, you need to define four things:

FieldDescriptionRequest URLThe API endpoint (e.g. https://planradar.com/api/v1/projects/{id}/tickets)MethodThe HTTP verb: GET, POST, PUT, or DELETERequest BodyThe JSON payload for POST and PUT requestsResponse SchemaThe expected structure of the response — tells PRC what data to expect so it can create a data tree for use in subsequent steps

Tip: When constructing request bodies manually, paste your JSON into an online formatter or validator before running the recipe. Malformed JSON is one of the most common causes of HTTP step failures and can be frustrating to diagnose inside the recipe builder.

Setting Up the Response Schema

The response schema is what allows PRC to parse the API response and expose its fields as data pills in subsequent steps. Without a correctly configured schema, you cannot map response data forward in your recipe.

How to populate the response schema:

1. Get a real API response — either from the API Documentation's "Try it out" feature, or by capturing the response from the browser network tab.

2. Copy the full JSON response.

3. Paste it into the Response Schema field in the HTTP tool configuration.

4. PRC will parse it and automatically create the data tree.

⚠️ Warning: Response Schemas Can Go Stale

If you add new custom fields to a project or otherwise change the schema of a PlanRadar object after your recipe was built, the response schema stored in your HTTP step will no longer match what the API actually returns.

Symptoms: steps that previously mapped data correctly will stop passing values, or mappings will appear blank.

Fix: Capture a fresh API response that includes the new fields and paste it into the response schema field to refresh it.

Alternative: Raw Body + parse_json (for Frequently Changing Schemas)

If you are working with an endpoint where the schema changes regularly — for example, because users add custom fields — manually refreshing the schema every time is impractical. In these cases, you can skip the fixed response schema entirely and parse the response dynamically.

How it works:

Configure the HTTP action to return the raw response body as a string (do not define a response schema). Then access individual fields in downstream steps using the parse_json formula:

response_body.parse_json["field_name"]

For nested fields:

response_body.parse_json["ticket"]["custom_fields"][0]["value"]

Why this is more resilient: The raw body always contains the full API response, regardless of schema changes. Any new field added to PlanRadar is immediately accessible by its key name — no step reconfiguration required.

Trade-off: You lose the visual data pill selector for that step's output. Field names must be typed manually in downstream steps rather than selected from a dropdown.

When to use which approach:

SituationRecommended approachStable endpoint, schema unlikely to changeFixed response schema (normal HTTP setup)Endpoint where PlanRadar custom fields can be added by usersRaw body + parse_jsonPlanRadar connector action available for the operationUse the connector — its schema is dynamic and always up to date

Note: The PlanRadar connector's ticket create/update actions use a dynamic schema that rebuilds at runtime based on project and ticket type. Custom fields added in PlanRadar are automatically reflected. This staleness issue only affects the HTTP connector.

Troubleshooting: Empty Data Pills in Downstream Steps

If data pills in steps after an HTTP action are empty or null, a slow server response is usually not the cause. Workato HTTP steps are synchronous — they wait for the full response before continuing. A slow server makes the step take longer, but does not produce empty output.

The most common actual causes are:

Quick diagnostic: Add a Logger step immediately after your HTTP step and log response_body as a string. This shows you exactly what Workato received — before any schema parsing — and is the fastest way to rule out a schema issue vs. a server issue.