Processing and Delivery

The Reminder plugin uses a background processor to check for pending reminders and deliver them at their scheduled times. This page explains how the processor works, how retries are handled, and how to trigger or control delivery.

Background Processing Flow

The processor is triggered by an external scheduler calling:

POST /api/reminder/item/pending/send?secret=dfg34sdcf

This endpoint is called periodically (e.g., every minute by a cron job or Azure Function). Each invocation:

1. Acquires a distributed Redis lock to prevent concurrent processing across multiple instances.
2. Queries all active reminder items whose nextSendTime is on or before the current time.
3. Groups results by agentId, configurationId, countryCode, and phoneNumber.
4. Processes each group in parallel batches (batch size is configurable).
5. Releases the Redis lock when processing is complete.

If another instance is already holding the lock, the incoming request exits immediately without processing. The lock TTL and renewal interval are configurable, ensuring the lock is not held indefinitely if a processor instance crashes.

Delivery Steps per Reminder

For each pending reminder, the processor:

1. Retrieves the configuration and checks that serverState is running. If paused, the reminder is skipped.
2. Calls the Dialog service's notification template endpoint with the recipient's phone number, country code, template name, and parameters.
3. On success:
   • Sets lastSendTime to now.
   • Resets lastAttempts to 0.
   • Advances nextSendTime to the next scheduled time in the list.
   • If no more send times remain, sets status to completed and records completedDate.
   • Appends a Sent entry to the history.
   • Calls the configured webhook URL with the updated status.
4. On failure:
   • Increments lastAttempts.
   • If lastAttempts reaches 5, skips the current send time and advances to the next one.
   • Appends a SendFailed or SendError entry to the history.

Retry Logic

Each send time in the reminder's schedule allows up to five delivery attempts. The attempt counter (lastAttempts) resets to zero after each successful delivery or when the processor advances to the next send time.

Manual Send Trigger

You can trigger delivery of a specific reminder immediately, bypassing the scheduled time:

POST /api/reminder/item/send?agentId={agentId}&configurationId={configurationId}&reminderId={reminderId}&secret=dfg34sdcf

This performs the same delivery steps as background processing for that single reminder item. Useful for testing or urgent re-delivery.

Validation before manual send:

• Notification key must be set on the configuration.
• Reminder must have a phone number and a template name.
• Configuration's Dialog service URI must be reachable.

Server State

Each configuration has a serverState of either running or paused. The processor checks this state for every group before sending.

• Running — reminders are delivered as scheduled.
• Paused — reminders are queued but not sent. No data is lost; delivery resumes automatically when the state is set back to running.

Update server state:

PUT /api/reminder/configuration/{agentId}/{configurationId}/server-state

{
  "serverState": "paused"
}

All state changes are recorded in an audit log. See Plugin Setup for details.

Delivery to Dialog Service

The processor calls the Dialog service's AutoTrigger API endpoint to deliver each notification template. The request includes:

• The recipient's countryCode and phoneNumber
• The notificationTemplateName
• The templateParameters list
• The notificationKey from the configuration (authorization header)
• The accountCode from the configuration (messaging account)

The Dialog service routes the message to the appropriate messaging channel and returns success or failure.

Configuration Variables

Related Pages

• Plugin Setup — server state and credentials.
• Create Reminder Items — fields and status lifecycle.
• Webhook Notifications — callbacks fired after each delivery.
• Reminder Overview