Through the Call HTTP Request tool, an Agent or Copilot can call external APIs, interact with third-party systems, and execute real business operations.

For example, you can use it to:

This article will guide you step by step according to the actual operation flow.

Enter the target Agent or Copilot, open the Tools page, click Add tool, and then select Call HTTP Request.

A dialog window for adding the tool will appear. You need to complete three basic settings first:

In the Select connection dropdown, choose an available connection in the current application.

The selected connection determines:

For example:

After selecting a connection, the connection type will be displayed automatically.

It is important to note:

The connection type is not manually selected here, but automatically determined by the connection you choose.
It is only for display in the add dialog and is a read-only field. It cannot be modified after entering the configuration page.

Currently supported connection types:

If you need to change the type later, you must create a new tool and select the connection again.

Enter the tool name in the Name field.

The name does not need to be unique, but it is recommended to clearly describe the tool’s purpose for easier identification. For example:

After entering the name, you can choose:

If you want to complete the configuration in one go, it is recommended to select Add and configure.

After entering the configuration page, the system will automatically load the connection information selected in the previous step.

The page is usually divided into several sections from top to bottom:

The following sections will be explained one by one in this order.

The Details section at the top of the page mainly includes:

The name is usually carried over from the previous page and can be modified if needed.

The name is the display name of the tool in the current Agent or Copilot.

It is recommended to use business-oriented naming instead of purely technical naming. This is because this name not only helps administrators identify it, but also helps you more easily understand what each tool is used for in the future.

The description is used to tell the system and future maintainers what this tool does and under what conditions it should be used.

Although this is not an API parameter, it is very important.
It is recommended to clearly write the following three points in the description:

In the Tool section, you will see that the current tool type is Call HTTP Request.
In the Connection section, you will see:

This connection information is for display purposes only and is not used to reselect the connection on this page. That is to say, at this stage, the connection type has already been fixed.

At this point, you need to first understand one thing:

The connection type you selected earlier will affect what settings appear on this page.
And this difference is not exactly the same between Agent and Copilot.

If the connection type you selected earlier is HTTP API, then no additional authorization settings will usually appear on the configuration page.

This is because under HTTP API mode, the tool simply calls the API directly. It does not involve user login and does not involve “which user identity is used to execute”.

Whether in Agent or Copilot, the behavior is basically the same:

This mode is more suitable for:

If the connection type you selected earlier is OAuth 2.0 API, then additional authorization-related settings will appear on the page.

However, it should be noted that the behavior in Agent and Copilot is different.

In Agent, OAuth 2.0 usually uses pre-configured authorization.

That is to say, this type of tool generally calls the API based on the authorization that has already been configured in the connection. The key point is whether the connection is currently available.

You will see that the connection type is OAuth 2.0 API, and the connection status is displayed, for example, Connected.

This mode is more oriented toward system execution rather than requiring end users to participate in authorization. Therefore, in Agent, it usually does not emphasize “user login before execution” like Copilot does.

This approach is more suitable for:

In Copilot, if the connection type is OAuth 2.0 API, additional on-demand authorization settings will usually appear.

At this time, you will see an authorization method dropdown, which typically includes the following two options:

These two options determine under whose identity the API is ultimately called.

After selecting this option, Copilot will directly use the account configured in the connection to call the API.
This is suitable for scenarios where unified system notifications are sent, shared resources are accessed, or there is no need to distinguish the current user’s identity.

After selecting this option, the end user will be required to sign in and authorize with their own account the first time they use the tool.
If the user has not yet authorized, the system will prompt them to sign in at runtime.

This mode is suitable for:

Therefore, the OAuth 2.0 mode in Copilot adds an extra layer of “user context” capability compared to Agent.
This is also the biggest difference between the two in terms of connection settings.

After understanding the connection types, you can continue to configure the Request section.

This section defines how the API will be called.

In the Method field, select the request method.

If your API is used to retrieve data, you should generally select GET.
If your API is used to submit data, you should generally select POST.

In the HTTP address field, enter the API endpoint to be called.

Depending on the connection, you can enter either a full URL or a relative path.
For example:

Which format to use depends on your connection configuration and the API requirements.

This field determines which API the tool will ultimately call, so accuracy is very important.

If your API requires headers, you can configure them here.

For example:

If you are using an OAuth 2.0 connection, in many cases authentication will be handled automatically, and you do not need to manually provide the Authorization header.
If you are using an HTTP API connection, you may need to add authentication headers yourself.

If the API requires a request body, a content type must usually be specified.
The most common one is JSON.

This setting determines how the system parses the request body you provide.

When the method is POST, you usually need to define a request body.
The request body is typically in JSON format. You can either write fixed values or reference input parameters.

For example:

Here, {{keyword}} and {{userId}} are not fixed values. They will be populated at runtime from Inputs.

So you can understand:

The Body defines the structure of the API request,
while Inputs define where the values come from.

Next is the Inputs section.

This section is used to define:

What parameters are required when the tool runs, and how those parameters are filled.

Click Add input parameter to add parameters one by one.

Each input row includes:

When Fill using = Dynamically fill with AI, clicking Customize allows you to:

This helps the calling agent correctly construct parameters for the target agent.

Next is the Completion section.

This section determines how the system handles the result after the tool execution is completed.

A common setting is Wait for response.

After selecting this option, the system will wait for the API to return a result before proceeding.

If the API response needs to be used by the Agent, this option should generally be selected.

This setting determines whether the result should be directly shown to the user.

For example:

If “No response” is selected, it means that although the API returns a result, the system will not directly display it to the user. Instead, the Agent will decide how to use the data internally.

When “Wait for response” is selected, you can configure outputs.

Common outputs include:

Where:

These outputs can be used by the current Agent or passed to other tools for further processing.

If you want to perform additional logic based on the API response, this step is important.

After completing all the settings, click Save.

It is recommended to test the tool immediately and confirm:

If you are a beginner, the most confusing part is usually choosing the connection type and usage scenario. You can understand it this way:

If you are calling a fixed API and do not need user identity, prioritize using HTTP API.

If the API requires account-based authorization, such as Outlook or Microsoft Graph, then use OAuth 2.0 API.

If you are using an Agent, it is more suitable for system-level, fixed authorization scenarios.
If you are using Copilot and want the end user to execute actions with their own identity, then you should choose OAuth 2.0 and select “Ask user to sign in when used”.

The configuration of the Call HTTP Request tool can be understood in three steps:

First, select the connection when adding the tool to determine the connection type.
Then, understand whether additional authorization settings will appear based on the connection type.
Finally, complete the configuration of request, inputs, and outputs.

For beginners, the two most important points to remember are:

First, the connection type is determined when the tool is created and cannot be changed in the configuration page.
​ Second, OAuth 2.0 behaves differently in Agent and Copilot, and Copilot supports user login for execution.

Once you understand these two key points, the configuration of Request, Inputs, and Outputs will become much clearer.