Connections
Every connection here exists for one reason: to remove a step where a person retypes something a machine already knows. They are grouped by what that step is, not by vendor logo.
So Tore can start work the moment something breaks, instead of waiting for a customer to notice and write in.
So an investigation reads the real file, the real commit and the real callers, and so a fix can be opened for your engineer to approve.
So the queue reaches people where they already are, and a reply from there reaches the customer.
So a support conversation becomes a tracked item without anyone retyping it, and closing that item updates the customer.
Analytics, billing and automation tools, so customer context arrives with the conversation and events can flow out to whatever you already run.
When we do not have one
Webhooks push events out as they happen
Signed with a hash over the exact body, retried three times with backoff, redirects not followed, and addresses that are not publicly routable refused. Every attempt is kept with its status code, so a delivery question is a lookup.
Webhooks and API keysRules can act without a connector at all
A workflow can post to a webhook, send an email, tag, assign or open a ticket when something happens, and every run is recorded with the reason it acted or deliberately did not.
How workflows runThe honest limit: a connection marked coming is not partially working. It is not wired, and pointing Tore at it will do nothing until it is. If one of them is the reason you would buy, write to us before you do.
Your error tracker and your code. With those two connected, an investigation can start before anyone writes in and finish as a pull request somebody reviews.