Go to the Channel Catalog to learn more about what plans have access to this channel. Sign into Quickbase, and then go to Pipelines > Channels.
Webhooks are user-defined HTTP callbacks, triggered by some event. When that event occurs, the source site makes an HTTP request to the URL configured for the webhook. Users can configure them to cause events on one site to invoke behavior on another.
The built-in Webhooks channel allows you to make API calls to third party systems from a pipeline. When you create or import a new pipeline, a new unique webhook url is created. For information about connecting with Pipelines Agent, see Quickbase Pipelines Agent connections.
Note: This channel is intended for developers and technically savvy pipeline builders.
Steps
The steps you can use with Webhooks fall into two categories: Requests and JSON Requests
| Type | Name | Description |
|---|---|---|
| Requests | ||
| Trigger | Incoming Request |
Triggers when you make an HTTP request to an auto-generated webhook endpoint. The default authentication schema is No Authentication. JWT Auth The only supported authentication method for the Incoming Request step is JWT Token. When you select the JWT Token option, you need to provide a public key and select a signing algorithm.
If verification fails, the pipeline does NOT get triggered, instead we return response with status code 401 (Unauthorized). |
| Action | Make Request |
Makes a HTTP request. HTTP responses are limited to 32MB to help prevent memory issues. Requests larger than 32MB will return an error. Authentication - choose the format of authentication (http basic, http digest, Oauth), if any. Basic The client sends the user name and password as unencrypted base64 encoded text. It should only be used with HTTPS, as the password can be easily captured and reused over HTTP. Digest - The client sends a hashed form of the password to the server. Although, the password cannot be captured over HTTP, it may be possible to replay requests using the hashed password. OAuth 2.0 - Open Authorization is a standard designed to allow a website or application to access resources hosted by other web apps on behalf of a user. Username - The user name for this request. For OAuth 2.0, this is your client_id. Passsword - The password for this user. For OAuth 2.0, this is your client_secret. Token URL - The token url refresh for OAuth 2.0. Oauth Credentials Placement - The location of the OAuth 2.0 credentials, Header, body, or both. Disable SSL Certificate Validation - Yes/No to turn on or off SSL/TLS certificaiton. Proxy Connection via On-Premises - Yes/No to turn on or off the proxy connection for the On-Premises agent. URL - A valid URL for the request. Method - The method, GET, POST, etc. for the request. Content type - The Content-Type header value for the HTTP request, choose Headers (list) - Name - the name of the header you want to reference, for example Value - the value of the header you want to reference, for example Body - Based on the selected content type, the use body field to send JSON, XML text as a payload, using the selected method. |
| JSON Requests | ||
| Trigger | Request for JSONP |
JSONP (JSON with Padding) builds on this technique and provides us with a way to access the returned data. It does this by having the server return JSON data wrapped in a function call (the “padding”) which can then be interpreted by the browser. This function must be defined in the page evaluating the JSONP response. The condition for the trigger, is set, starts with, etc. If you choose starts with, for example, you'll need to supply the characters the method starts with. You can add additional conditions with ADD and OR with one or more of the following: Header Name - the name of the header you want to reference, for example Header Value - the value of the header you want to reference, for example Body JSON - If you have JSON payload, the advanced expression displays, for example: Origin IP - the condition for the trigger, is set, starts with, etc. If you choose starts with, for example, you'll need to supply the numbers the IP starts with. URL Parms - A valid URL for the request. The condition for the trigger, is set, starts with, etc. If you choose starts with, for example, you'll need to supply the text that the Result starts with. You can also add additional conditions with ADD and OR. Result - text from the result. Result link - text from the result link. Expression - you add a jinja filter here to refine your selection. For more information about jinja, see About jinja. |
| Action | JSONP Response |
Takes action only on JSON responses. JSON Request - choose the Request you want to operate on from the dropdown. Payload - Drag and drop fields from below into the input field. Callback Name - Click to display available names: |
Constructing headers
To construct headers, you can iterate over a list from another step. If a header and respective value contains newlines, each line in the name and corresponding line in value are treated as a Header: Value pair. For example having a Name “X-One↵X-Two” and a Value “one↵two” will result in two headers: “X-One: One” and “X-Two: two” (↵ stands for a newline, like pressing the enter key). For example:
Header->Name
Header->Values
HEADER_1
HEADER_2
HEADER_3
in Values:
value 1
value 2
value 3
Construct a request that includes UTF-8 characters
When constructing the request and the XML payload in the Make Request step, you must specifically declare that the payload you’re sending uses the UTF-8 characters set. Quickbase Pipelines preserves the non-ascii characters and uses UTF-8 internally for that. In order to convey this UTF-8 data to the external tool you need to:
- Put the
Content-Type: application/xml; charset=utf-8HTTP header as part of the Make Request step headers. - Have the declaration on top of the XML document “<?xml version=“1.0” encoding=“UTF-8"?>” to specify it contains non-ASCII chars which are encoded using UTF-8.
- When using jinja to interpolate your values inside the XML, make sure to pass the values with the escape jinja filter to escape special ASCII characters.
- Check that the external system supports CLM documents in UTF-8 encoding.
Example XML payload using jinja:
<?xml version="1.0" encoding="UTF-8"?> <note> <to>{{a.target_name|escape}}</to> <from>{{a.sender_name|escape}}</from> <heading>{{a.topic|escape}}</heading> <body>{{a.message|escape}}</body> </note>
When a webhook is successful
When a webhook is successful, it will appear in the activity log with a status response of 200 if it's successful, like this:
Use case examples
The following are some example of using the webhook channel.
Webhook urls and mailparser
When you create or import a new pipeline, a new unique webhook url is created. This has implications in the mailparser app. For example:
-
You create or reimport an existing pipeline for mailparser. A new webhook url is automatically generated:
Since the url has changed, you'll need to update it in your mailparser account. -
Copy the new URL and open your mailparser account inbox.
-
In mailparser, click on the integration section:
-
Edit your defined Generic Webhook to reflect the new url and save the changes: