Overview
The Royalti.io notification system keeps users informed about important events across your workspace through multiple delivery channels. This guide covers how to retrieve, manage, and customize notification preferences for your users.Why Use Notifications?
- Stay Informed: Get real-time updates about critical events in your workspace
- Multi-Channel Delivery: Receive notifications via in-app, email, and push notifications
- Customizable: Control which events trigger notifications and through which channels
- Centralized: All notifications are accessible through a unified API
- Actionable: Notifications link directly to relevant resources for quick action
Notification Channels
Royalti.io supports three notification channels:| Channel | Description | Use Case |
|---|---|---|
IN_APP | In-app notifications displayed in the Royalti dashboard | Real-time updates while users are actively working |
EMAIL | Email notifications sent to user’s registered email address | Important updates that require user attention |
PUSH | Push notifications sent to mobile devices | Urgent updates when users are away from the dashboard |
Notification Types
Royalti.io generates notifications for events across multiple categories:Royalty File Processing
| Event Type | Description | Default Channels |
|---|---|---|
ROYALTY_FILE_UPLOADED | Royalty file uploaded successfully | IN_APP |
ROYALTY_FILE_PROCESSED | Royalty file processing completed | IN_APP, EMAIL |
ROYALTY_FILE_PROCESSING_FAILED | Royalty file processing failed | IN_APP, EMAIL |
ROYALTY_FILE_DELETED | Royalty file deleted | IN_APP |
User & Collaboration Events
| Event Type | Description | Default Channels |
|---|---|---|
USER_CREATED | New user added to workspace | IN_APP |
USER_UPDATED | User profile or permissions modified | IN_APP |
USER_DEACTIVATED | User account deactivated | IN_APP |
USER_DELETED | User removed from workspace | IN_APP, EMAIL |
USER_INVITATION_SENT | User invited to workspace | IN_APP, EMAIL |
USER_ADDED_TO_SPLIT | User added to revenue split | IN_APP, EMAIL |
USER_REMOVED_FROM_SPLIT | User removed from revenue split | IN_APP |
Artist Management
| Event Type | Description | Default Channels |
|---|---|---|
ARTIST_CREATED | New artist profile created | IN_APP |
ARTIST_UPDATED | Artist profile modified | IN_APP |
ARTIST_DEACTIVATED | Artist profile deactivated | IN_APP |
ARTIST_DELETED | Artist profile removed | IN_APP, EMAIL |
ARTIST_AUTO_CREATED | Artist automatically created during processing | IN_APP |
ARTIST_RESOLUTION_FAILED | Failed to resolve artist information | IN_APP |
Catalog Management (Tracks & Releases)
| Event Type | Description | Default Channels |
|---|---|---|
ASSET_CREATED | New asset (track) added | IN_APP |
ASSET_UPDATED | Asset modified | IN_APP |
ASSET_DEACTIVATED | Asset deactivated | IN_APP |
ASSET_DELETED | Asset removed | IN_APP, EMAIL |
PRODUCT_CREATED | New product (album/release) created | IN_APP |
PRODUCT_UPDATED | Product modified | IN_APP |
PRODUCT_DEACTIVATED | Product deactivated | IN_APP |
PRODUCT_DELETED | Product removed | IN_APP, EMAIL |
Financial & Payment Events
| Event Type | Description | Default Channels |
|---|---|---|
PAYMENT_REQUEST_SENT | Payment request created | IN_APP, EMAIL |
PAYMENT_REQUEST_APPROVED | Payment request approved | IN_APP, EMAIL |
PAYMENT_REQUEST_REJECTED | Payment request rejected | IN_APP, EMAIL |
PAYMENT_MADE_PROCESSING | Payment being processed | IN_APP |
PAYMENT_MADE_COMPLETED | Payment successfully completed | IN_APP, EMAIL |
PAYMENT_MADE_FAILED | Payment failed | IN_APP, EMAIL |
PAYMENT_PROCESSING | Payment in processing state | IN_APP |
PAYMENT_COMPLETED | Payment completed | IN_APP |
PAYMENT_DELETED | Payment record deleted | IN_APP |
REVENUE_CREATED | Revenue entry created | IN_APP |
REVENUE_UPDATED | Revenue entry modified | IN_APP |
REVENUE_DELETED | Revenue entry deleted | IN_APP, EMAIL |
EXPENSE_CREATED | Expense entry created | IN_APP |
EXPENSE_UPDATED | Expense entry modified | IN_APP |
EXPENSE_DELETED | Expense entry deleted | IN_APP, EMAIL |
Billing & Subscription
| Event Type | Description | Default Channels |
|---|---|---|
BILLING_SUCCESS | Billing operation successful | IN_APP, EMAIL |
BILLING_ERROR | Billing operation failed | IN_APP, EMAIL |
BILLING_WARNING | Billing warning or issue | IN_APP, EMAIL |
Release Management & Distribution
| Event Type | Description | Default Channels |
|---|---|---|
RELEASE_SUBMITTED | Release submitted for review | IN_APP, EMAIL |
RELEASE_APPROVED | Release approved for distribution | IN_APP, EMAIL |
RELEASE_REJECTED | Release rejected | IN_APP, EMAIL |
RELEASE_FEEDBACK_ADDED | Feedback added to release | IN_APP, EMAIL |
RELEASE_AUTO_CREATED | Release automatically created | IN_APP |
RELEASE_AUTO_CREATION_FAILED | Auto-creation of release failed | IN_APP |
RELEASE_UPDATED_MANAGEMENT | Release updated by management | IN_APP |
RELEASE_CREATED | Release created | IN_APP |
RELEASE_DELETED | Release deleted | IN_APP |
RELEASE_ERROR | Release processing error | IN_APP, EMAIL |
RELEASE_STATUS_REVERTED | Release status reverted | IN_APP |
File Processing
| Event Type | Description | Default Channels |
|---|---|---|
FILE_PROCESSING_STARTED | File processing initiated | IN_APP |
FILE_PROCESSING_COMPLETE | File processing completed | IN_APP |
FILE_PROCESSING_FAILED | File processing failed | IN_APP, EMAIL |
DDEX Provider Delivery
| Event Type | Description | Default Channels |
|---|---|---|
PROVIDER_DELIVERY_INITIATED | Delivery to provider started | IN_APP |
PROVIDER_DELIVERY_COMPLETED | Delivery to provider completed | IN_APP, EMAIL |
PROVIDER_DELIVERY_FAILED | Delivery to provider failed | IN_APP, EMAIL |
PROVIDER_DELIVERY_ACKNOWLEDGED | Provider acknowledged delivery | IN_APP |
PROVIDER_STATUS_UPDATE | Provider status update received | IN_APP |
Default Notification Configuration
When users first sign up or are invited to a workspace, Royalti.io automatically creates smart default notification preferences based on event priority and importance.Default Settings Overview
Philosophy: In-app notifications for all events, email only for high-priority actions that require attention or represent critical workflow changes.Disabled by Default
These low-priority CRUD events are disabled by default to reduce notification noise:| Event Type | Reason for Disabling |
|---|---|
ARTIST_CREATED | Routine catalog management |
ARTIST_UPDATED | Frequent updates, low urgency |
ASSET_CREATED | High-volume event in active workspaces |
ASSET_UPDATED | Frequent metadata changes |
PRODUCT_CREATED | Routine release management |
EXPENSE_CREATED | Financial data entry |
EXPENSE_UPDATED | Routine financial updates |
REVENUE_CREATED | Financial data entry |
REVENUE_UPDATED | Routine financial updates |
PAYMENT_PROCESSING | Intermediate state, not actionable |
PAYMENT_DELETED | Administrative action, low urgency |
Email-Enabled by Default
These high-priority events include both in-app and email notifications by default: Royalty File Processing (Critical)ROYALTY_FILE_PROCESSED- Completion requires reviewROYALTY_FILE_PROCESSING_FAILED- Requires immediate attention
PAYMENT_REQUEST_SENT- Approval workflow initiatedPAYMENT_REQUEST_APPROVED- Financial decision confirmedPAYMENT_REQUEST_REJECTED- Requires follow-up action
USER_INVITATION_SENT- New team member notificationUSER_ADDED_TO_SPLIT- Revenue sharing change
ARTIST_DELETED,ASSET_DELETED,PRODUCT_DELETEDEXPENSE_DELETED,REVENUE_DELETED,USER_DELETED
RELEASE_SUBMITTED- Distribution workflow stepRELEASE_APPROVED,RELEASE_REJECTED- Decision notificationRELEASE_FEEDBACK_ADDED- Requires review
In-App Only by Default
All other notification types use in-app notifications only by default. Users receive these notifications in the dashboard but not via email unless they explicitly enable email delivery.Customizing Defaults
Admin Note: Default preferences are automatically initialized when:- A new user signs up
- A user accepts an invitation
- A user logs in for the first time
Quick Start
1
Get Notifications
Retrieve notifications for the authenticated user:Response:
2
Check Unread Count
Get the count of unread notifications:Response:
3
Mark as Read
Mark a specific notification as read:Or mark all notifications as read:
4
Configure Preferences
Customize notification preferences:
Notification Structure
All notifications follow a standardized structure:Field Descriptions
| Field | Type | Description |
|---|---|---|
id | string (UUID) | Unique notification identifier |
type | string | Notification type from NotificationType enum |
title | string | Short notification title |
content | string | Detailed notification message |
resourceType | string | Type of resource the notification relates to |
resourceId | string | ID of the related resource |
actionUrl | string | URL to navigate to when notification is clicked |
isRead | boolean | Whether the notification has been read |
isImportant | boolean | Whether the notification is marked as important |
isArchived | boolean | Whether the notification is archived |
metadata | object | Additional event-specific data |
expiresAt | ISO 8601 | When the notification expires (null for no expiration) |
TenantId | integer | Workspace ID |
TenantUserId | string (UUID) | User ID the notification is for |
createdAt | ISO 8601 | When the notification was created |
updatedAt | ISO 8601 | When the notification was last updated |
API Endpoints
Get Notifications
Retrieve paginated notifications with optional filtering. Endpoint:GET /notifications
Query Parameters:
| Parameter | Type | Default | Description |
|---|---|---|---|
page | integer | 1 | Page number |
pageSize | integer | 20 | Number of items per page |
isRead | boolean | - | Filter by read status |
isArchived | boolean | - | Filter by archived status |
type | string | - | Filter by notification type |
Get Unread Count
Get the count of unread notifications for quick badge display. Endpoint:GET /notifications/unread/count
Example:
Mark Notification as Read
Mark a specific notification as read. Endpoint:PATCH /notifications/{notificationId}/read
Path Parameters:
| Parameter | Type | Required | Description |
|---|---|---|---|
notificationId | string (UUID) | Yes | ID of the notification |
Mark All Notifications as Read
Mark all notifications as read for the authenticated user. Endpoint:PATCH /notifications/mark-all-read
Example:
Notification Preferences
Users can customize which notifications they receive and through which channels.Get Notification Preferences
Retrieve the current notification preferences for the authenticated user. Endpoint:GET /notifications/preferences
Example:
Update Notification Preferences
Customize which notifications to receive and through which channels. Endpoint:PUT /notifications/preferences
Request Body:
Preference Configuration
Available Channels
| Channel | Description | Delivery Time |
|---|---|---|
EMAIL | Email to registered address | Immediate or batched (hourly aggregation) |
IN_APP | In-app notification in dashboard | Real-time |
PUSH | Push notification to mobile device | Real-time |
Notification Batching
Some notification types support batching to reduce email volume:- Immediate: Critical notifications (payments, failures) are sent immediately
- Hourly Aggregation: Non-critical notifications (asset created, updates) are batched and sent hourly
- Daily Cleanup: Expired notifications are automatically removed
Integration Patterns
Real-Time Notification Display
Implement a notification bell with unread count:Notification List Component
Fetch and display notifications with pagination:Preference Management UI
Allow users to customize notification preferences:Best Practices
✅ User Experience- Display unread count prominently in your UI (bell icon with badge)
- Mark notifications as read when user views them
- Provide action links to relevant resources when applicable
- Group similar notifications to reduce clutter
- Auto-refresh notification count periodically (every 30-60 seconds)
- Show timestamps in user-friendly format (e.g., “5 minutes ago”)
- Highlight important notifications with visual indicators
- Allow bulk actions (mark all as read, archive, etc.)
- Use pagination to limit the number of notifications loaded at once
- Cache unread count to reduce API calls
- Implement lazy loading for notification details
- Batch preference updates when changing multiple settings
- Use WebSockets or polling for real-time updates (if available)
- Provide granular controls for each notification type
- Set sensible defaults based on notification importance
- Allow channel-specific preferences (email vs. in-app vs. push)
- Explain notification types so users understand what they’re opting into
- Respect user preferences immediately - no delay in applying changes
- Don’t overwhelm users with too many notifications
- Don’t ignore unread status - always mark as read when viewed
- Don’t hardcode notification types - use the API to get available types
- Don’t skip error handling - API calls may fail
- Don’t forget to implement pagination - notification lists can grow large
Troubleshooting
Notifications Not Appearing
✅ Checklist:- Check notification preferences - is the event type enabled?
- Verify the user has the correct permissions
- Check if notifications are filtered by
isReadorisArchived - Ensure the tenant ID matches the authenticated user’s workspace
- Check the API response for errors
Missing Notification Preferences
✅ Solutions:- Preferences are created on-demand when first updated
- Default preferences are used if none are set
- Call
GET /notifications/preferencesto see current state - Update preferences with
PUT /notifications/preferences
High Unread Count
✅ Management:- Implement “Mark all as read” functionality
- Allow users to archive old notifications
- Set expiration dates for less important notifications
- Encourage users to customize preferences to reduce noise
FAQ
Can I receive notifications for events from other users in my workspace?
Can I receive notifications for events from other users in my workspace?
Yes, notifications are workspace-scoped. When events occur in your workspace (e.g., a teammate creates an asset), all relevant users receive notifications based on their preferences and permissions.
How long are notifications stored?
How long are notifications stored?
Notifications are stored indefinitely unless they have an
expiresAt date. Expired notifications are automatically removed by the daily cleanup job at 2 AM UTC.Can I disable all notifications?
Can I disable all notifications?
Yes, you can disable notifications by setting
isEnabled: false for each notification type in your preferences. Alternatively, you can choose to only enable the IN_APP channel and manage notifications within the dashboard.Are notifications sent in real-time?
Are notifications sent in real-time?
In-app and push notifications are sent in real-time. Email notifications for non-critical events may be batched and sent hourly to reduce email volume. Critical notifications (payments, failures) are always sent immediately.
Can I get notifications for specific artists or products only?
Can I get notifications for specific artists or products only?
Currently, notifications are workspace-level and cannot be filtered by specific resources. You can control notification types and channels, but not individual resources. This feature may be added in future updates.
What happens if notification delivery fails?
What happens if notification delivery fails?
Failed notifications are automatically retried based on the channel’s retry strategy. If all retry attempts fail, the notification is logged for debugging but the in-app notification remains accessible through the API.
Can I customize notification templates?
Can I customize notification templates?
Notification templates are currently managed by Royalti.io and cannot be customized per workspace. However, you can control which notifications you receive through your preferences.
Support & Resources
API Documentation:- Notifications API Reference - Complete API documentation
- User Management - Managing workspace users
- Webhook Integration - Real-time event notifications to external systems
- Support Portal - Get help from our support team
- Status Page - Check system status and uptime
Last Updated: January 2025 Version: 1.0