Webhooks

Webhooks Overview

Dash Webhooks allow your systems to stay in sync with card-related events in real time. When an action is taken against a card (e.g., status change, replacement), Dash receives notifications from the card processor and forwards them to your registered webhook endpoint(s).

You can:

• Use a single endpoint to handle all events (recommended for simplicity), or
• Create dedicated endpoints per event type.

Always inspect the "event" field in the payload to determine how to handle the incoming data.

Supported Events

Card Status Events

1 POST HTTP/1.1
2 Content-Type: application/json 3{
4  "event": "card.status.change",
5  "targetIdentifier": "string",
6  "subscriptionIdentifier": "string",
7  "customerIdentifier": "string",
8  "proxy": "string",
9  "status": "string"
10  }

Handle Status Event Webhook – Dash Webhooks API v0.0.1

Card Replacement Events

1 POST HTTP/1.1
2 Content-Type: application/json 3{
4  "event": "card.replacement",
5  "targetIdentifier": "string",
6  "subscriptionIdentifier": "string",
7  "customerIdentifier": "string",
8  "newCardIdentifier": "string",
9  "originalProxy": "string",
10  "newProxy": "string"
11  }

Handle Replacement Event Webhook – Dash Webhooks API v0.0.1

Note: Identifiers like targetIdentifier, subscriptionIdentifier, and newCardIdentifier are relevant only for a small subset of v3 customers. Most clients can ignore these fields.

Environments & Testing

• Production Only: Webhooks are currently available only in the production environment.
• Testing Guidance: To simulate webhook behavior in lower environments (DEV/UAT), mock payloads and POST them to your handler endpoints. This helps validate your architecture under load.

Security & Authentication

• Dash connects via HTTPS using TLS 1.3.
• Only endpoints with SSL certificates from publicly trusted authorities are accepted.
• You may provide custom authentication headers (e.g., Authorization: Bearer YOUR_TOKEN) when registering your endpoint.
• Dash expects the full header string, including the key and value.

Enrollment Instructions

To register your webhook endpoint, please send the following details via secure email to Dash Solutions:

• Handler URL(s): The endpoint(s) Dash should POST to
• Authentication Headers: Any required headers (e.g., API key, bearer token)

Note: Automatic enrollment is not available at this time.

Delivery & Reliability

• Dash sends each event only once.
• Events are backed by message queues at both the card processor and Dash for reliability.
• We recommend clients also enqueue received events (e.g., pub-sub architecture) to avoid processing failures.
• Webhooks should be treated as supplemental notifications, not the sole source of truth. Always fetch the latest data via Dash APIs when needed.

Frequently Asked Questions

Q: Can we verify that a webhook request is from Dash?
A: Yes. You may provide a custom header name and value that Dash will include in each request.

Q: Are webhooks signed or include a nonce?
A: No. Dash does not sign webhook payloads or include a nonce. The design encourages clients to fetch data using identifiers rather than relying on payload integrity.

Q: Can we whitelist Dash’s IPs?
A: Yes. Dash uses a static public IP pool.

Q: Is there an event ID for idempotency?
A: No event ID is included. The system is designed to notify you of changes, not to serve as a transactional log.