To forward notifications to 📨🚕, your source system must support sending messages via webhooks, a feature available in most modern services and tools.

📨🚕 generates a unique per-application webhook endpoint that allows you to receive and route notifications through your configured destinations (XMPP, Matrix, etc.).

Webhook Endpoint Structure

Each application in 📨🚕 has its own dedicated webhook URL, unless the application is of type “Pushover”. The endpoint is automatically created when you register a new application. The URL format is:

POST https://via.msg.taxi/{token}

Replace {token} with your application’s unique webhook token.

Supported Content Types

📨🚕 accepts a wide range of payload formats to maximize compatibility:

• application/json
• application/x-www-form-urlencoded
• multipart/form-data
• application/xml / text/xml

These are parsed automatically, there’s no need to adjust anything in your sender.

Webhook Formats

📨🚕 supports two formats for incoming webhook payloads:

Pushover-Compatible Format

A drop-in replacement for Pushover’s API , making it trivial to switch your existing Pushover setup to 📨🚕 without code changes.

Example payload:

{
  "token": "abc123",
  "user": "xyz456",
  "message": "Server is down!",
  "title": "Alert"
}

If you’re using tools that support Pushover out of the box, simply change the endpoint URL, token and user to your 📨🚕 webhook, token and user key and you’re done.

The token as well as the user key can be found inside your application.

Custom Format (templated)

For non-standard payloads or services like Grafana, Prometheus, GitHub Actions, Zapier, etc., 📨🚕 provides a flexible templating system based on Go’s text/template syntax.

You can define how 📨🚕 should extract fields like Message, Title, Priority, etc. from the incoming webhook.

Example: Custom JSON Payload

Incoming JSON:

{
  "alerts": [
    {
      "title": "Server Down",
      "message": "The server is not responding.",
      "severity": "critical"
    }
  ]
}

Your custom template fields in 📨🚕:

• Message:

{{ webhook "body.alerts.0.message" }}

• Title:

{{ webhook "body.alerts.0.title" }}

• Priority:

{{ webhook "body.alerts.0.severity" }}

This setup tells 📨🚕 to extract the message from a nested field in the payload using dot notation, making it compatible with deeply nested structures.

Use the webhook function to access parsed body fields: webhook "body.foo.bar". All fields in the 📨🚕 dashboard (Message, Title, URL, Priority, etc.) can be templated independently.

If you are unsure what the source system will send, you can use the preview in the right “Latest input” pane to figure it out. For a preview to become available, your source system needs to send at least one message. Set up your application, confirm it and leave all custom format fields empty, then trigger a notification by the source system and check the preview.

Security Considerations

• Each webhook endpoint is tied to a unique token — treat this like an API key.
• Do not expose your token in public repositories or client-side code.
• If a token is compromised, rotate it by generating a new application and deleting the old one.
• User keys and application tokens can not be used to log in to the [console].