System and service status operations
- Update NATS notification channel
Vilna API (1.0.0)
Welcome to the Vilna API Reference. This is the complete OpenAPI specification for all API endpoints.
Quick Links
- API Overview - Introduction and concepts
- Security Guide - Authentication and webhook verification
- CAIP Standards - Asset identification standards
- Quick Start Guide - Step-by-step integration tutorial
API Endpoints
Asset Management
- Assets - Discover and manage digital assets
Address Operations
- Addresses - Manage blockchain addresses
- Extended Public Keys - HD wallet management
Monitoring and Notifications
- Transactions - Transaction monitoring
System
- Blockchains - Information on supported blockchains
- System Status - Health checks and version info
Need Help?
Visit our documentation portal for detailed guides and examples.
Filter notification channels by their delivery type.
When specified, only channels of the given type will be returned:
nats— NATS subject-based messaging channelstelegram— Telegram bot message delivery channelswebhook— HTTP webhook callback channels
Filter notification channels by their archived status.
true— Returns only archived (disabled) channelsfalse— Returns only active (enabled) channels- Omit parameter — Returns both active and archived channels
Archived channels are temporarily disabled but retain their configuration for potential reactivation later.
Search notification channels by name using case-insensitive pattern matching.
The search is performed on the channel name field using SQL ILIKE pattern matching:
- Partial matches are supported
- Case-insensitive search
- Whitespace is normalized
Examples:
"webhook"— matches channels with "webhook" in the name"prod"— matches "Production Alerts", "prod-monitoring", etc."alert"— matches "System Alerts", "Critical Alert Channel", etc.
- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels
- Production environmenthttps://demo.vilna.app/v1/notification_channels
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
'https://docs.vilna.io/_mock/apis/spec/notification_channels?limit=20&page=1&kind=webhook&is_archived=true&search=production&sort_by=name' \
-H 'X-Api-Key: YOUR_API_KEY_HERE'List of notification channels with pagination
Unique identifier in UUID format
Defines the type of notification delivery channel.
Each kind determines the transport mechanism and configuration structure:
- nats — NATS subject-based messaging for internal microservice communication
- telegram — Telegram bot message delivery to chats or direct messages
- webhook — HTTP POST callbacks to external endpoints
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
NATS server URL for connection.
Specifies the NATS server endpoint where notifications will be published. Supports various NATS URL formats:
nats://localhost:4222- Standard NATS connectionnats://user:[email protected]:4222- With authentication
Security Note: URLs containing credentials should be handled securely and may be masked in API responses.
NATS subject (topic) where notifications will be published.
Subjects are hierarchical and use dot notation (e.g., "notifications.alerts.critical"). Wildcards can be used for subscription patterns:
*matches any single token>matches any number of tokens at the end
Examples:
- "notifications.system.alerts"
- "events.user.created"
- "monitoring.metrics.cpu"
Indicates whether the notification channel is archived (disabled)
Timestamp when the resource was created
{ "items": [ { … }, { … }, { … } ], "meta": { "page": 1, "limit": 30, "total": 15, "total_pages": 1 } }
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
NATS server URL for connection.
Specifies the NATS server endpoint where notifications will be published. Supports various NATS URL formats:
nats://localhost:4222- Standard NATS connectionnats://user:[email protected]:4222- With authentication
Security Note: URLs containing credentials should be handled securely and may be masked in API responses.
NATS subject (topic) where notifications will be published.
Subjects are hierarchical and use dot notation (e.g., "notifications.alerts.critical"). Wildcards can be used for subscription patterns:
*matches any single token>matches any number of tokens at the end
Examples:
- "notifications.system.alerts"
- "events.user.created"
- "monitoring.metrics.cpu"
- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels/nats
- Production environmenthttps://demo.vilna.app/v1/notification_channels/nats
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://docs.vilna.io/_mock/apis/spec/notification_channels/nats \
-H 'Content-Type: application/json' \
-H 'X-Api-Key: YOUR_API_KEY_HERE' \
-d '{
"name": "System Alerts NATS",
"url": "nats://nats.example.com:4222",
"subject": "notifications.system.alerts"
}'Notification channel details
Unique identifier in UUID format
Defines the type of notification delivery channel.
Each kind determines the transport mechanism and configuration structure:
- nats — NATS subject-based messaging for internal microservice communication
- telegram — Telegram bot message delivery to chats or direct messages
- webhook — HTTP POST callbacks to external endpoints
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
NATS server URL for connection.
Specifies the NATS server endpoint where notifications will be published. Supports various NATS URL formats:
nats://localhost:4222- Standard NATS connectionnats://user:[email protected]:4222- With authentication
Security Note: URLs containing credentials should be handled securely and may be masked in API responses.
NATS subject (topic) where notifications will be published.
Subjects are hierarchical and use dot notation (e.g., "notifications.alerts.critical"). Wildcards can be used for subscription patterns:
*matches any single token>matches any number of tokens at the end
Examples:
- "notifications.system.alerts"
- "events.user.created"
- "monitoring.metrics.cpu"
Indicates whether the notification channel is archived (disabled)
Timestamp when the resource was created
{ "id": "550e8400-e29b-41d4-a716-446655440000", "kind": "nats", "name": "System Alerts NATS", "config": { "url": "nats://nats.example.com:4222", "subject": "notifications.system.alerts" }, "is_archived": false, "created_at": "2024-01-15T10:30:00Z", "updated_at": "2024-01-15T10:30:00Z" }
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
NATS server URL for connection.
Specifies the NATS server endpoint where notifications will be published. Supports various NATS URL formats:
nats://localhost:4222- Standard NATS connectionnats://user:[email protected]:4222- With authentication
Security Note: URLs containing credentials should be handled securely and may be masked in API responses.
NATS subject (topic) where notifications will be published.
Subjects are hierarchical and use dot notation (e.g., "notifications.alerts.critical"). Wildcards can be used for subscription patterns:
*matches any single token>matches any number of tokens at the end
Examples:
- "notifications.system.alerts"
- "events.user.created"
- "monitoring.metrics.cpu"
- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels/nats/{notification_channel_id}
- Production environmenthttps://demo.vilna.app/v1/notification_channels/nats/{notification_channel_id}
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X PATCH \
https://docs.vilna.io/_mock/apis/spec/notification_channels/nats/550e8400-e29b-41d4-a716-446655440000 \
-H 'Content-Type: application/json' \
-H 'X-Api-Key: YOUR_API_KEY_HERE' \
-d '{
"name": "Updated NATS Channel"
}'Notification channel details
Unique identifier in UUID format
Defines the type of notification delivery channel.
Each kind determines the transport mechanism and configuration structure:
- nats — NATS subject-based messaging for internal microservice communication
- telegram — Telegram bot message delivery to chats or direct messages
- webhook — HTTP POST callbacks to external endpoints
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
NATS server URL for connection.
Specifies the NATS server endpoint where notifications will be published. Supports various NATS URL formats:
nats://localhost:4222- Standard NATS connectionnats://user:[email protected]:4222- With authentication
Security Note: URLs containing credentials should be handled securely and may be masked in API responses.
NATS subject (topic) where notifications will be published.
Subjects are hierarchical and use dot notation (e.g., "notifications.alerts.critical"). Wildcards can be used for subscription patterns:
*matches any single token>matches any number of tokens at the end
Examples:
- "notifications.system.alerts"
- "events.user.created"
- "monitoring.metrics.cpu"
Indicates whether the notification channel is archived (disabled)
Timestamp when the resource was created
{ "id": "550e8400-e29b-41d4-a716-446655440000", "kind": "nats", "name": "System Alerts NATS", "config": { "url": "nats://nats.example.com:4222", "subject": "notifications.system.alerts" }, "is_archived": false, "created_at": "2024-01-15T10:30:00Z", "updated_at": "2024-01-15T10:30:00Z" }
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
Telegram Bot API token obtained from @BotFather.
Format: {bot_id}:{auth_token} Example: "123456789:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
Security Note: This is sensitive data and should be handled securely. In some API responses, this may be masked or omitted.
Telegram chat ID where notifications will be sent.
Chat ID formats:
- Private chats (positive numbers)
- Group chats (negative numbers)
- Channel chats (negative numbers starting with -100)
You can obtain chat IDs by:
- Adding the bot to a chat and using /start command
- Using Telegram Bot API methods like getUpdates
- Using @userinfobot for user/chat information
- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels/telegram
- Production environmenthttps://demo.vilna.app/v1/notification_channels/telegram
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://docs.vilna.io/_mock/apis/spec/notification_channels/telegram \
-H 'Content-Type: application/json' \
-H 'X-Api-Key: YOUR_API_KEY_HERE' \
-d '{
"name": "Production Alerts",
"bot_token": "987654321:ABCDEFGHIJKLMNOPQRSTUVWXYZ123456789",
"chat_id": -1001234567890
}'Notification channel details
Unique identifier in UUID format
Defines the type of notification delivery channel.
Each kind determines the transport mechanism and configuration structure:
- nats — NATS subject-based messaging for internal microservice communication
- telegram — Telegram bot message delivery to chats or direct messages
- webhook — HTTP POST callbacks to external endpoints
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
NATS server URL for connection.
Specifies the NATS server endpoint where notifications will be published. Supports various NATS URL formats:
nats://localhost:4222- Standard NATS connectionnats://user:[email protected]:4222- With authentication
Security Note: URLs containing credentials should be handled securely and may be masked in API responses.
NATS subject (topic) where notifications will be published.
Subjects are hierarchical and use dot notation (e.g., "notifications.alerts.critical"). Wildcards can be used for subscription patterns:
*matches any single token>matches any number of tokens at the end
Examples:
- "notifications.system.alerts"
- "events.user.created"
- "monitoring.metrics.cpu"
Indicates whether the notification channel is archived (disabled)
Timestamp when the resource was created
{ "id": "550e8400-e29b-41d4-a716-446655440000", "kind": "nats", "name": "System Alerts NATS", "config": { "url": "nats://nats.example.com:4222", "subject": "notifications.system.alerts" }, "is_archived": false, "created_at": "2024-01-15T10:30:00Z", "updated_at": "2024-01-15T10:30:00Z" }
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
Telegram Bot API token obtained from @BotFather.
Format: {bot_id}:{auth_token} Example: "123456789:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
Security Note: This is sensitive data and should be handled securely. In some API responses, this may be masked or omitted.
Telegram chat ID where notifications will be sent.
Chat ID formats:
- Private chats (positive numbers)
- Group chats (negative numbers)
- Channel chats (negative numbers starting with -100)
You can obtain chat IDs by:
- Adding the bot to a chat and using /start command
- Using Telegram Bot API methods like getUpdates
- Using @userinfobot for user/chat information
- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels/telegram/{notification_channel_id}
- Production environmenthttps://demo.vilna.app/v1/notification_channels/telegram/{notification_channel_id}
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X PATCH \
https://docs.vilna.io/_mock/apis/spec/notification_channels/telegram/550e8400-e29b-41d4-a716-446655440000 \
-H 'Content-Type: application/json' \
-H 'X-Api-Key: YOUR_API_KEY_HERE' \
-d '{
"name": "Updated Telegram Channel"
}'Notification channel details
Unique identifier in UUID format
Defines the type of notification delivery channel.
Each kind determines the transport mechanism and configuration structure:
- nats — NATS subject-based messaging for internal microservice communication
- telegram — Telegram bot message delivery to chats or direct messages
- webhook — HTTP POST callbacks to external endpoints
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
NATS server URL for connection.
Specifies the NATS server endpoint where notifications will be published. Supports various NATS URL formats:
nats://localhost:4222- Standard NATS connectionnats://user:[email protected]:4222- With authentication
Security Note: URLs containing credentials should be handled securely and may be masked in API responses.
NATS subject (topic) where notifications will be published.
Subjects are hierarchical and use dot notation (e.g., "notifications.alerts.critical"). Wildcards can be used for subscription patterns:
*matches any single token>matches any number of tokens at the end
Examples:
- "notifications.system.alerts"
- "events.user.created"
- "monitoring.metrics.cpu"
Indicates whether the notification channel is archived (disabled)
Timestamp when the resource was created
{ "id": "550e8400-e29b-41d4-a716-446655440000", "kind": "nats", "name": "System Alerts NATS", "config": { "url": "nats://nats.example.com:4222", "subject": "notifications.system.alerts" }, "is_archived": false, "created_at": "2024-01-15T10:30:00Z", "updated_at": "2024-01-15T10:30:00Z" }
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
HTTP/HTTPS URL endpoint where notification webhooks will be sent.
The URL must be accessible from the notification service and should accept POST requests with JSON payloads. Only HTTP and HTTPS protocols are supported for security reasons.
Security Note: URLs containing sensitive information (API keys in query params) should use headers for authentication instead.
Optional HTTP headers to include with webhook requests.
Commonly used for:
- Authentication: "Authorization: Bearer token"
- Content type: "Content-Type: application/json"
- API keys: "X-API-Key: your-api-key"
- Custom headers for routing or identification
Security Note: Sensitive headers (tokens, API keys) should be handled securely and may be masked in API responses.
- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels/webhook
- Production environmenthttps://demo.vilna.app/v1/notification_channels/webhook
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://docs.vilna.io/_mock/apis/spec/notification_channels/webhook \
-H 'Content-Type: application/json' \
-H 'X-Api-Key: YOUR_API_KEY_HERE' \
-d '{
"name": "Production Alerts Webhook",
"url": "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX",
"headers": {
"Authorization": "Bearer token123"
}
}'Notification channel details
Unique identifier in UUID format
Defines the type of notification delivery channel.
Each kind determines the transport mechanism and configuration structure:
- nats — NATS subject-based messaging for internal microservice communication
- telegram — Telegram bot message delivery to chats or direct messages
- webhook — HTTP POST callbacks to external endpoints
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
NATS server URL for connection.
Specifies the NATS server endpoint where notifications will be published. Supports various NATS URL formats:
nats://localhost:4222- Standard NATS connectionnats://user:[email protected]:4222- With authentication
Security Note: URLs containing credentials should be handled securely and may be masked in API responses.
NATS subject (topic) where notifications will be published.
Subjects are hierarchical and use dot notation (e.g., "notifications.alerts.critical"). Wildcards can be used for subscription patterns:
*matches any single token>matches any number of tokens at the end
Examples:
- "notifications.system.alerts"
- "events.user.created"
- "monitoring.metrics.cpu"
Indicates whether the notification channel is archived (disabled)
Timestamp when the resource was created
{ "id": "550e8400-e29b-41d4-a716-446655440000", "kind": "nats", "name": "System Alerts NATS", "config": { "url": "nats://nats.example.com:4222", "subject": "notifications.system.alerts" }, "is_archived": false, "created_at": "2024-01-15T10:30:00Z", "updated_at": "2024-01-15T10:30:00Z" }
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
HTTP/HTTPS URL endpoint where notification webhooks will be sent.
The URL must be accessible from the notification service and should accept POST requests with JSON payloads. Only HTTP and HTTPS protocols are supported for security reasons.
Security Note: URLs containing sensitive information (API keys in query params) should use headers for authentication instead.
Optional HTTP headers to include with webhook requests.
Commonly used for:
- Authentication: "Authorization: Bearer token"
- Content type: "Content-Type: application/json"
- API keys: "X-API-Key: your-api-key"
- Custom headers for routing or identification
Security Note: Sensitive headers (tokens, API keys) should be handled securely and may be masked in API responses.
- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels/webhook/{notification_channel_id}
- Production environmenthttps://demo.vilna.app/v1/notification_channels/webhook/{notification_channel_id}
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X PATCH \
https://docs.vilna.io/_mock/apis/spec/notification_channels/webhook/550e8400-e29b-41d4-a716-446655440000 \
-H 'Content-Type: application/json' \
-H 'X-Api-Key: YOUR_API_KEY_HERE' \
-d '{
"name": "Updated Webhook Channel"
}'Notification channel details
Unique identifier in UUID format
Defines the type of notification delivery channel.
Each kind determines the transport mechanism and configuration structure:
- nats — NATS subject-based messaging for internal microservice communication
- telegram — Telegram bot message delivery to chats or direct messages
- webhook — HTTP POST callbacks to external endpoints
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
NATS server URL for connection.
Specifies the NATS server endpoint where notifications will be published. Supports various NATS URL formats:
nats://localhost:4222- Standard NATS connectionnats://user:[email protected]:4222- With authentication
Security Note: URLs containing credentials should be handled securely and may be masked in API responses.
NATS subject (topic) where notifications will be published.
Subjects are hierarchical and use dot notation (e.g., "notifications.alerts.critical"). Wildcards can be used for subscription patterns:
*matches any single token>matches any number of tokens at the end
Examples:
- "notifications.system.alerts"
- "events.user.created"
- "monitoring.metrics.cpu"
Indicates whether the notification channel is archived (disabled)
Timestamp when the resource was created
{ "id": "550e8400-e29b-41d4-a716-446655440000", "kind": "nats", "name": "System Alerts NATS", "config": { "url": "nats://nats.example.com:4222", "subject": "notifications.system.alerts" }, "is_archived": false, "created_at": "2024-01-15T10:30:00Z", "updated_at": "2024-01-15T10:30:00Z" }
- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels/{notification_channel_id}
- Production environmenthttps://demo.vilna.app/v1/notification_channels/{notification_channel_id}
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
https://docs.vilna.io/_mock/apis/spec/notification_channels/550e8400-e29b-41d4-a716-446655440000 \
-H 'X-Api-Key: YOUR_API_KEY_HERE'Notification channel details
Unique identifier in UUID format
Defines the type of notification delivery channel.
Each kind determines the transport mechanism and configuration structure:
- nats — NATS subject-based messaging for internal microservice communication
- telegram — Telegram bot message delivery to chats or direct messages
- webhook — HTTP POST callbacks to external endpoints
User-defined human-readable name for the notification channel.
Used to identify and distinguish between different notification channels. The name should be descriptive and help users understand the purpose or destination of the channel.
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
Configuration structure for notification channels. The exact schema depends on the channel kind.
Each channel type has specific configuration requirements:
- NATS channels require a subject for message routing
- Telegram channels require bot token and chat ID for message delivery
- Webhook channels require URL and optional headers/authentication
NATS server URL for connection.
Specifies the NATS server endpoint where notifications will be published. Supports various NATS URL formats:
nats://localhost:4222- Standard NATS connectionnats://user:[email protected]:4222- With authentication
Security Note: URLs containing credentials should be handled securely and may be masked in API responses.
NATS subject (topic) where notifications will be published.
Subjects are hierarchical and use dot notation (e.g., "notifications.alerts.critical"). Wildcards can be used for subscription patterns:
*matches any single token>matches any number of tokens at the end
Examples:
- "notifications.system.alerts"
- "events.user.created"
- "monitoring.metrics.cpu"
Indicates whether the notification channel is archived (disabled)
Timestamp when the resource was created
{ "id": "550e8400-e29b-41d4-a716-446655440000", "kind": "nats", "name": "System Alerts NATS", "config": { "url": "nats://nats.example.com:4222", "subject": "notifications.system.alerts" }, "is_archived": false, "created_at": "2024-01-15T10:30:00Z", "updated_at": "2024-01-15T10:30:00Z" }
- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels/{notification_channel_id}
- Production environmenthttps://demo.vilna.app/v1/notification_channels/{notification_channel_id}
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X DELETE \
https://docs.vilna.io/_mock/apis/spec/notification_channels/550e8400-e29b-41d4-a716-446655440000 \
-H 'X-Api-Key: YOUR_API_KEY_HERE'- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels/{notification_channel_id}/actions/archive
- Production environmenthttps://demo.vilna.app/v1/notification_channels/{notification_channel_id}/actions/archive
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://docs.vilna.io/_mock/apis/spec/notification_channels/550e8400-e29b-41d4-a716-446655440000/actions/archive \
-H 'X-Api-Key: YOUR_API_KEY_HERE'- Mock serverhttps://docs.vilna.io/_mock/apis/spec/notification_channels/{notification_channel_id}/actions/restore
- Production environmenthttps://demo.vilna.app/v1/notification_channels/{notification_channel_id}/actions/restore
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://docs.vilna.io/_mock/apis/spec/notification_channels/550e8400-e29b-41d4-a716-446655440000/actions/restore \
-H 'X-Api-Key: YOUR_API_KEY_HERE'