Skip to content
PulsVaultDocs
Get started
Solo ProTeamBusinessEnterprise

Integrations

Connect Slack and webhooks once, then point alerts at named destinations — per project if you want. Credentials are stored encrypted and never shown again.

An integration is a third-party service PulsVault can send messages to — today Slack and generic webhooks. You connect it once, add one or more destinations to it, and everything that needs to reach you refers to a destination by name.

Manage them under Ops → DevOps → Configure → Integrations, beside the alert routes that use them. On the Solo Professional plan the same page is also under App settings → Slack & webhooks (in the Integrations group of the App settings sidebar). Team, Business and Enterprise organizations configure their integrations only in DevOps — the organization settings address redirects there, and the App settings entry is not shown. Managing integrations needs the Manage DevOps environments permission; an organization can give it to a custom role without making that person an administrator. An integration belongs to that space, so everyone with access uses the same destinations rather than each person pasting their own URL somewhere.

Why destinations, not one URL

A Slack incoming webhook posts to exactly one channel and cannot be repointed at another. So "our Slack" is never a single URL — it is a list of them, one per channel. Modelling it that way is what lets each project alert its own channel while still being one integration you manage in one place.

Slack#

Select Add Slack (or Connect Slack on an empty page), then add a destination for each channel you want to reach. Each destination has a name you choose (#platform-oncall, Payments team) and the webhook URL from Slack.

Creating the webhook in Slack is a short one-time setup — see Connecting Slack.

Webhooks#

A webhook destination is any HTTPS endpoint you control. PulsVault sends a JSON body describing what happened, so you can route messages into your own tooling — an incident manager, a chatops bot, a log pipeline.

Optionally give the destination a signing secret. When one is set, each request carries an X-PulsVault-Signature header holding an HMAC of the body, so your endpoint can verify the request came from PulsVault and was not modified in transit. Compare it using a constant-time comparison and reject anything that does not match.

Public endpoints only

A destination must be reachable from the public internet. Addresses inside private networks — loopback, 10.x, 192.168.x, 172.16–31.x, link-local including the 169.254.169.254 cloud-metadata address, and their IPv6 equivalents — are refused when you save them. If your receiver lives inside a private network, put a small public relay in front of it.

Naming destinations well#

The name is what you will pick from a dropdown months later, on a screen that does not show the URL. #platform-oncall tells you where a message lands; Slack 2 does not.

Testing a destination#

Every destination has Send test, which delivers a real message through the same path a genuine notification takes. Use it when you add a destination and after you rotate one — a destination that has never been tested is a guess.

The result is kept with the destination, so when it was last tested and whether it worked is visible later, not only in the seconds after you press the button.

Rotating a credential#

A Slack webhook URL, and a webhook signing secret, are credentials: anyone holding the URL can post to that channel. PulsVault stores them encrypted and never shows them again — the destination list displays only an identifying hint such as hooks.slack.com/services/T04ABC/B05XYZ/•••.

To rotate one:

  1. Create the replacement in the provider (a new Slack webhook, a new secret at your endpoint).
  2. Open the destination in PulsVault and paste the new value over the old one.
  3. Send test to confirm the new one works.
  4. Delete the old webhook in the provider.
Leaving the field blank keeps the current value

When you edit a destination, the credential field starts empty because the stored value is never sent back to your browser. Blank means keep what is stored — you only type in it when you are deliberately replacing the credential. Clearing a destination's credential is not possible by accident.

Where destinations are used#

Today, alert routes for credential validation point at them: a route names one or more destinations, and every alert it carries is delivered there.

Because routes reference destinations rather than embedding a URL, rotating a Slack webhook is one edit in one place — every route using it keeps working, and none of them had a copy of the credential to begin with.

Was this page helpful?