The HTTP Request command in IBM RPA is a practical way to integrate automations with REST APIs and web services. It sends an HTTP request to a target URL using the configured method, headers, and body options, and returns the response content plus metadata such as status code and headers.

This article walks through common patterns, such as GET, POST with JSON, custom headers, cookies, proxy settings and finishes with an advanced scenario: calling an mTLS-protected endpoint using a client certificate.

What the command does (and a few important details)

A few behaviors are useful to know before building flows:

• The command supports HTTP/1.1 only.
• It automatically creates standard headers such as Accept, Accept-Encoding, User-Agent, Content-Type, Host, Content-Length, and Expect: 100-continue (values depend on OS, formatter, URL, body, etc.).
• It supports input parameters like Headers, Content Headers, Cookie Container, Proxy, Ignore Global Proxy Configuration, and Timeout (default timeout is 5 seconds).

Example A: Simple GET

A GET request is the quickest way to validate connectivity and parse a response.

Suggested test endpoint: https://postman-echo.com/get (it’s a request/response test service).

Configuration

• Method: GET
• URL: https://postman-echo.com/get
• Map outputs to variables (success, value/response, statusCode, reasonPhrase)

Example B: POST JSON

When sending JSON (POST/PUT/PATCH), the command requires a Formatter and then either a Body or other body-related fields depending on your scenario.

Configuration

• Method: POST
• Formatter: JSON
• Body: JSON payload (Text / Http Content)

Example C: Proxy and timeout (common in corporate networks)

In IBM RPA, the HTTP Request command can route traffic through a proxy. When enabled, the flag Ignore Global Proxy Configuration makes the command ignores the global proxy configured in the IBM RPA Client/installation settings. This is useful when the machine has a corporate proxy configured globally, but a specific automation must use a different proxy (or no proxy at all).

In practice:

• To use the global proxy: leave Ignore Global Proxy Configuration disabled.

• To use a custom proxy for just this request: Enable Ignore Global Proxy Configuration and set Proxywith a variable of type Proxy

Advanced example: mTLS using a client certificate

Mutual TLS (mTLS) is a common pattern for APIs that require the client to authenticate with a certificate (in addition to the usual server-side TLS). Starting in IBM RPA 30.0.1, the HTTP Request command supports attaching a client certificate to the request so the target server can validate the caller.

To use it, select a certificate file in one of the supported formats:

• .cert (certificate only), or

• .pfx (PKCS#12 container that includes the certificate and private key).

If a PFX is used, its password is required. This password is not sent in the HTTP request, it is used only locally to open/decrypt the PFX and load the private key so the certificate can be attached to the TLS handshake.

Practical way to test:

• badssl.com provides a client certificate download in PKCS#12 format (e.g., .p12) with the password shown in their table.

• A typical mTLS test endpoint is https://client.badssl.com/.

Without the certificate:

Security note (recommended)

Avoid hardcoding certificate passwords in scripts. Store secrets in the System Vault (Control Center credentials) and retrieve them at runtime using Get Vault Item (getVaultItem), which returns the password as a SecureString. SecureString is designed for sensitive values and is only kept during the bot’s runtime, reducing exposure in automation code and logs.

Conclusion

IBM RPA’s HTTP Request command provides a solid foundation for building API-driven automations, covering the most common integration needs such as GET/POST calls, custom headers, JSON payloads, cookie/session handling, and proxy configuration for corporate networks. It can also be used for more restricted environments by enabling access to mTLS-protected endpoints through client certificates. Client certificate support is limited to .pfx and .cert files; when using a .pfx (PKCS#12) certificate, a password is required to load the private key and complete the TLS handshake. Secret values (such as certificate passwords) should be stored in the System Vault and retrieved at runtime with Get Vault Item to keep credentials out of source code and better protected during execution. With these options, automations can securely communicate with both public APIs and enterprise-grade services that enforce stricter network and authentication policies.