Notifications configuration

Use this page to understand notification service and email notification fields for Ripple Custody. The example shows one possible configuration shape; SMTP provider, credentials, resource values, scaling, and delivery policy depend on your deployment.

The notification system handles notification processing, persistence, real-time delivery, and optional email delivery. Email notification settings are configured under harmonize.notifications.email. The notification service component is configured under components.notification.

Location: harmonize.notifications.email

SMTP port notes:

Location: components.notification

Resource and replica values are workload-dependent. Set them based on expected notification volume and observed runtime behavior.

OAuth credentials, database schema, and inter-service URLs are managed by the deployment configuration unless explicitly exposed.

The notification service uses built-in templates for notification categories such as transaction updates, approval requests, security alerts, system notifications, and custom application notifications.

• Email notifications require SMTP connection details.
• SMTP credentials should be supplied through your secret-management process.
• Notification persistence requires PostgreSQL connectivity.
• Event-driven notification processing depends on AMQP configuration.
• Notification APIs depend on OAuth authentication configuration.
• Run the notification service with a single replica. It keeps signature-polling state in process memory.
• When you upgrade to a release that includes server-issued verification codes, upgrade the notification service before the OAuth server and the web application. Both refuse to show a signing or login code that the notification service didn't issue.
• On startup, the notification service applies its database migrations automatically, including a one-time backfill that writes the legacy verification code onto signing requests created before the upgrade. The backfill isn't reversible. Without it, pending requests would be unsignable from an upgraded phone until they expired.

From the release that ships server-issued verification codes, the notification service generates the two-digit code that users match between the web UI and the Ripple Custody: Auth & Sign app. Mobile app versions earlier than 5.12.0 don't support server-issued codes, so the service ships with a compatibility mode that stores a legacy code alongside the server-issued one. While compatibility mode is on, older apps keep matching the web UI.

Turn compatibility mode off only when at least 95 percent of active devices have registered through the secure registration flow for 14 consecutive days. The service logs one line per device registration, Device registration received. with secured: true or secured: false, which gives you the adoption figure. After you turn the mode off, a device that still runs an older app shows a code that doesn't match the web UI and can't sign. If users report that the numbers don't match, turn compatibility mode back on and check that the affected users have updated the app. Turning it back on is a configuration change and a restart, not a redeployment.

This example shows email notification settings and the notification component in one deployment values file:

harmonize:
  notifications:
    email:
      enabled: true
      sender: "noreply@example.com"
      smtp:
        host: "smtp.example.com"
        port: "587"
        username: "<smtp-user>"
        password: "<smtp-password>"

components:
  notification:
    enabled: true
    replicas: 1
    resources:
      limits:
        cpu: 1000m
        memory: 1024Mi
      requests:
        cpu: 100m
        memory: 256Mi
    service:
      main:
        ports:
          http:
            port: 80
            targetPort: 3000

• OAuth server configuration
• AMQP configuration
• Networking configuration
• PostgreSQL configuration