We’re currently doing some private testing on our Incoming Webhooks integration. Want to be a part of it? Get in touch with us.
Stitch’s Incoming Webhooks integration provides a simple and flexible method to integrate any existing webhook API with Stitch. If Stitch doesn’t have a native integration for the webhook you want to integrate, then Stitch webhooks is your best bet.
With Stitch’s Incoming Webhooks integration, you have the ability to quickly and easily integrate with dozens of services that use webhook APIs. Some notable services include:
You need a Stitch account to use the Stitch webhooks integration.
In addition, the webhook API you want to use must meet the following requirements:
You can determine if the webhook API you want to use meets the above criteria by checking out their webhook API documentation. If you’re not sure or the docs are unclear, please reach out to support.
Defining a Primary Key is optional. The Incremental Replication Method Stitch uses will depend on whether a Primary Key is defined when the integration is initially created, however:
_sdc_primary_key.will be automatically generated. This is because Stitch requires Primary Keys to replicate data and prevent duplication.
We don’t recommend this, but yes, you can. Stitch uses Primary Keys to correctly replicate your data and prevent duplication; changing the Primary Key after the fact may result in fields not being updated correctly.
For instructions on how to set up webhooks in your provider’s app, refer to their documentation and reach out to their support team if you get lost. Depending on the provider you’re using, the steps for implementing webhooks may differ.
However: you can find setup articles in our docs for a few of the most popular apps that the Stitch Incoming Webhooks integration is compatible with, such as:
By design, most webhook-based integrations don’t retain historical data, as data is sent in real-time.
If the service you’re integrating with offers replay functionality, however, you may be able to send historical data to your Incoming Webhooks integration.
When the Primary Key isn’t defined during the setup process, Stitch will automatically generate a Primary Key column called
_sdc_primary_key. This is because Stitch requires Primary Keys to replicate data and prevent duplication.
In v1 of the Stitch Incoming Webhooks integration, Stitch will create a single table - called
data - in the webhook integration schema (this will be the name you enter in the Integration Schema field when you set up the integration) of your data warehouse.
The schema of an Incoming Webhooks table will contain two “types” of columns: columns used by Stitch (prepended with
_sdc) and the columns sent by the provider’s webhook API.
Aside from the Stitch columns, the schema of this table will depend entirely on the provider of the webhook API. For example: if the webhook API you integrate with only contains
value fields, these are the only fields that will be created in the
Stitch does not augment Incoming Webhook data, nor does it have any control over the fields sent by the webhook provider.
There are two reasons for this: one is the general nature of webhook data, and the other is how the Incoming Webhooks integration is designed.
The Stitch Incoming Webhook integration is designed to create only one top-level table. This single table will contain all the data that Stitch receives from your webhook, which can include several types of records. For example: if you set up Mandrill using Incoming Webhooks, your data table may contain records for whitelist events, click events, bounce events, and so on.
While each record type may contain some similar attributes (
id, created_at, etc.), it's likely that each record type will have its own set of attributes, which will only be populated for that record or other specific record types.
As such, some columns in some records will contain
NULLs. Here's an example with a Mandrill message send event, a whitelist add event, and a click event:
| id | ts | event | action | type | ip | url | |----+------------+-------+--------+-----------+-------------+---------------| | 1 | 1481730892 | send | NULL | NULL | NULL | NULL | | 2 | NULL | NULL | add | whitelist | NULL | NULL | | 3 | 1481732465 | click | NULL | NULL | 126.96.36.199 | http://hi.com | // record 1 is a message send event // record 2 is a whitelist add event // record 3 is a click event
That's true; we did. However: if you're using Redshift, Postgres, or Panoply as your data warehouse, you may see multiple tables in your Incoming Webhooks integration schema. These are subtables, which a result of Stitch deconstructing nested data structures so the data can be loaded into your data warehouse. If the provider you integrate with uses nested data structures, you'll see subtables.
To learn more about this Stitch feature and how to tie subtables together in your queries, click on the links in the above paragraph.
Our Technical Documentation Manager loves getting feedback and suggestions for docs. If you’re looking for something specific, write into support! We can’t promise that every suggestion will result in a new set of docs, but suggestions are welcomed and encouraged.