Send Request to External Services
Introduction
Webhook Node is an operation node that allows to send requests towards external services using HTTPS with IDHub workflows, seamlessly integrating with third-party API's, webhooks or endpoints. The node facilitates configuring the method, URL, query parameters, request body, authentication and response type. This document covers every one of the configurable field, what it does, when you should use it and how to use them in a practical sense.
How to Add Webhook Node to a Workflow?
- Log in to your IDHub tenant.
- Go to the IDHub Admin App.
- Click on “Workflows”.
- Click on the “Edit” icon where you would like to add the webhook node.
- In the workflow editor, drag the webhook node to the editor panel.
- You will be shown the node configuration in the RHS.
- Configure the node (This is discussed in the details below)
- Connect the node within the workflow where you would like to keep the node.
- After making the changes to the node, click on the update button at the bottom.
How to Configure Webhook Node?
Each field of the webhook node, along with descriptions and use-cases are discussed below.
HTTP Method
The HTTP Method field represents the operation to be performed on the destination. GET, POST, PUT, PATCH and DELETE are valid methods.
| Method Value | Description | Example Use Case |
|---|---|---|
| GET | Retrieve data from an API | Fetching user information from an external HR system. |
| POST | Submit or create data. | Create new JIRA Tickets. |
| PUT | Replace or create a resource at the given URL | Update JIRA issue fields |
| PATCH | Partially update an existing resource | Update a user's phone number |
| DELETE | Remove a resource identified by the URL | Delete a Jira Ticket. |
URL
The URL field indicates the entire endpoint to make a call to, including the protocol (https://) and path that follows. Use HTTPS only for security: IDHub requires secure connections which means it won't accept plain HTTP. The URL can contain path params or resource ids as required (e.g., /users/123 to the user with id 123).
Please do not include query parameters in the URL, as you will use the Query Parameters field for that. (they will be appended automatically).
| Use Case | Example URL |
|---|---|
| Slack incoming webhook | https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX |
| Google Chat webhook | https://chat.googleapis.com/v1/spaces/AAA/messages?key=API_KEYUse your service account or API credentials here. |
| JIRA REST API (create issue) | https://your-domain.atlassian.net/rest/api/3/issue |
Query Parameters
The Query Parameters field receives a JSON object containing the URL query strings. For example, entering {"status": "open", "sort": "created"} will append ?status=open&sort=created to the URL. Query parameters are widely used with GET requests (less commonly with other methods) to narrow the scope of the request. Every key–value pair from the JSON is added to the query string as a key=value pair (joined by &).
| Use Case | Example Query Parameters (JSON) |
|---|---|
| JIRA issue search | {"jql": "project=TEST AND status=\"Open\"","fields":"summary"} |
| GitHub list repos | {"visibility": "all", "affiliation": "owner"} |
| API filtering by status | {"status": "active", "limit": 50} |
Request Body (JSON)
The Request Body field represents data transmitted in the body of the HTTP request (as per the usual use case for POST, PUT, PATCH). You must enter valid JSON here. That will send this JSON as the request payload (content type: application/json). The content and format varies depending on the API of the target service. For example, in the case of messaging webhooks (Slack, Google Chat) this will typically be some type of JSON message object (e.g. with a "text"). And for REST APIs (JIRA, GitHub etc.) it would be the fields or data needed by the API (Issue Fields, Object's properties etc).
| Use Case | Request Body (JSON) |
|---|---|
| Slack message | {"text": "Deployment succeeded ✅"} |
| Google Chat message | {"text": "Build complete 👍", "space": "AAA"} |
| JIRA create issue | {"fields": {"project":{"key":"TEST"},"summary":"Issue created","issuetype":{"id":"10001"}}} |
Use Authentication
The Use Authentication toggle decides, whether or not the Authorization header should be added to the request. The various options are discussed below:
- No
- The request is sent without credentials. Most incoming webhooks (Slack, Google Chat) have no separate auth since the secret URL or an API key in the path is doing that part of security.
- Yes
- Includes authentication. If you've turned this option on, you will have to pick an Authentication Type as described below.
| Use Case | Use Authentication? |
|---|---|
| Slack incoming webhook | No |
| Google Chat webhook | No |
| JIRA REST API (cloud) | Yes |
Authentication Type
If Use Authentication is set to Yes, choose the Authentication Type. The options are:
- Basic Authentication – Sends credentials as HTTP Basic Auth.
- Token Authentication – Sends a bearer token in the header:
Authorization: Bearer <token> - IDHub Authentication – Authenticates via IDHub.
Authentication Token (for Token Auth)
When Token Authentication is enabled, input the string of token at Authentication Token. This is generally either a long token or JWT issued by the service. The node will output the Authorization: Bearer . For instance you may provide a GitHub personal access token or an OAuth2 access token.
| Use Case | Example Token (Bearer) |
|---|---|
| GitHub personal token | ghp_AbCdEfGhIjKlMnOpQrStUvWxYz1234 |
| Azure AD OAuth2 token | eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ij... |
Username and Password (for Basic Auth)
If Basic Authentication is selected, you will need to supply Username and Password. They are joined as username:password and Base64 encoded in the Authorization: Basic header. You should use your service account or API credentials instead.
| Use Case | Username | Password |
|---|---|---|
| JIRA Cloud API | jira_user@example.com | S3rv1ceP@ssw0rd |
| LDAP Directory (Bind) | cn=admin,dc=company | LDAP$ecret |
Response Type
IDHub uses the value of the Response Type field to interpret the service's response. Its options that are usually Text, JSON, Binary or Other:
- Text – Treat the response as plain text (a string). This is the default. Use this when the service returns human-readable text (like "OK" or HTML). For example, Slack’s webhook returns a simple text acknowledgment.
- JSON – Parse the response body as JSON. The node will parse it into an object/structure for downstream nodes. For example, most REST APIs (GitHub, JIRA, etc.) return JSON objects. If the response is not valid JSON, the parsed result will be null
- Binary – Treat the response as raw binary data (useful for file downloads). Under the hood, this corresponds to an array buffer or binary blob (e.g. image or PDF data)
- Other – For any other formats (e.g. XML)
| Use Case | Response Type |
|---|---|
| Slack webhook call | Text |
| Google Chat webhook | Text |
| JIRA REST API | JSON |