Automatic reminders

Automatic reminders are messages sent to a participant when they have a pending action (such as signing a document or filling in a form) that they have not yet completed. They can be configured when a Flow instance is created and modified at any later point through the participant reminder endpoints.

Configuring reminders

A reminder schedule can be set at instance creation through the automatic_reminders block in the settings of the Create Instance endpoint. In the following example, the schedule applies to every participant in the instance and uses email as the delivery method.

{
  "title": "Agreement signing",
  "settings": {
    "automatic_reminders": {
      "date": { "type": "relative", "days_delay": 5 },
      "method": "email"
    }
  },
  "participants": [
    { "label": "alice", "name": "Alice Cooper", "email": "alice@example.com" },
    { "label": "bob",   "name": "Bob Marley",   "email": "bob@example.com"   }
  ],
  "documents": [ ... ],
  "process": {
    "type": "parallel_all",
    "steps": [
      {
        "type": "sequence",
        "steps": [
          { "type": "sign",       "participant": "alice", "documents": ["agreement"] },
          { "type": "send_email", "participant": "alice", "template": "confirmation" },
          { "type": "sign",       "participant": "alice", "documents": ["appendix"]  }
        ]
      },
      { "type": "sign", "participant": "bob", "documents": ["agreement"] }
    ]
  }
}

When the instance starts, both Alice and Bob have a pending action: signing the agreement. An automatic email reminder is scheduled five days out for both of them.

Alice's branch then shows how reminders track pending actions over time. If Alice signs within five days, no reminder is sent. The next step, send_email, is not a pending action: it's a system action that sends a confirmation message and completes on its own, so it never triggers a reminder. The last step, signing the appendix, is a new pending action, so a fresh reminder is rescheduled five days from the moment she reaches that step. A relative reminder is therefore (re)scheduled each time a participant gains a new pending action, counting from that moment in time.

The method field is optional: if omitted, each participant's reminder is sent by email if they have an email address, otherwise by sms.

The Modify Reminder Settings endpoint (described below) lets you reconfigure the schedule or delivery method for a single participant after the instance has started.

The instance-level settings.automatic_reminders block is optional: if it is omitted, no reminders are scheduled by default and individual participants can opt in via the modify endpoint. Likewise, the participant's own automatic_reminders in the create request is optional too: if omitted, the instance-level settings are used for that participant.

Date format

The date block in a reminder configuration describes when the reminder should fire. It is either relative (a number of days from when the participant gains a pending action) or absolute (a fixed UTC date and time).

A relative date accepts an optional time for the time of day at which the reminder fires, in a given timezone. If time is omitted, the reminder fires days_delay days after the moment scheduling happens, at whatever clock time that works out to.

{
  "type": "relative",
  "days_delay": 5,
  "time": {
    "time_of_day": "09:00:00",
    "time_zone": "Europe/Stockholm"
  }
}

A relative date also accepts an optional repeat field, either never or periodically. With periodically, the reminder repeats every days_delay days at the same time, for as long as the participant has pending actions. Omitting the field is equivalent to never.

An absolute date pins the reminder to a specific UTC date and time. It must be at least 24 hours in the future and within one year from now.

{
  "type": "absolute",
  "date_time": "2026-09-01T09:00:00Z"
}

Modifying reminders at runtime

Reminder settings can be changed after the instance has started, as long as it is still in progress.

The Modify Reminder Settings endpoint replaces the current reminder settings for a single participant if present, and reschedules the next reminder accordingly. If a participant has no reminder settings, the same endpoint can set them up. It takes the same JSON shape as a participant's automatic_reminders block at instance creation:

{
  "date": { "type": "relative", "days_delay": 7 },
  "method": "email"
}

The new schedule is reflected immediately in the Get Instance endpoint response under the participant's automatic_reminder field.

The Cancel Reminder endpoint removes the currently scheduled reminder for a single participant without changing their reminder settings. The next time the participant gains a new pending action, a new reminder is scheduled from the existing settings.

The Delete Reminder Settings endpoint removes the participant's reminder configuration entirely. Any currently scheduled reminder is cancelled, and no new reminders are scheduled for that participant until new settings are configured via a modify call.

Validation

When creating an instance or modifying reminder settings, the requested delivery method must match the contact details available for the participant:

• email requires an email address on file.
• sms requires a phone number on file.
• email_and_sms requires both.

If a participant doesn't have the email address or phone number their reminder needs, the create instance or modify call is rejected. This prevents reminders from silently failing to deliver later.

The reminder date must also be valid:

• Absolute dates must be at least 24 hours in the future, and at most one year ahead.
• Relative dates must specify a days_delay between 1 and 365.
• The time_zone of a relative date must be a valid time zone name, such as Europe/Stockholm.

Invalid dates are rejected.

When reminders fire

Reminders are delivered only if the participant still has a pending action when the reminder is scheduled to fire. If the participant has completed their action in the meantime, the reminder is dropped and nothing is sent. No further reminders are scheduled for that action either.

If a reminder for a given participant is rescheduled before it has fired, either by a modify call or because the participant gains a new pending action, only the latest scheduled reminder fires. Earlier scheduled reminders for the same participant are discarded.

Reminders are sent in the instance's settings.language.