Skip to main content
A destination is where deliveries go. You create it once in the Console (Outbound actions) or with the SDK, subscribe it to triggers, and Olira keeps sending there until you disable it. The destination object is the same in both places: type, URL or email, subscribed triggers, optional digest batching, status, and a signing secret.

Destination types

These are the types you can create today. New types will appear in the same Console picker and the same SDK create call; you will not need a different subscription or delivery model. Webhook URLs must be public HTTPS. http://, localhost, and private or internal addresses are rejected when you save the destination and again every time Olira sends to it.
Store the signing secret as soon as it is shown. It is returned in plaintext once at create, and once if you rotate it; after that only the last four characters are visible. See Receiving deliveries.

Triggers

A trigger is the kind of occurrence that causes a delivery. Subscribe a destination to the ones you care about — in the Console, by ticking them; in the SDK, by passing subscribed_triggers (Python) or subscribedTriggers (C#). Currently available triggers: Pass ["*"] (or ActionTrigger.ALL / ActionTrigger.All) to subscribe to every currently available trigger. Because "*" is evaluated by the platform rather than by this list, that subscription could start receiving additional trigger types later. A typo’d plain string is not caught client-side; it reaches the server as a 422.

Immediate delivery vs. digest batching

By default, every trigger fires its own delivery right away. For a high-frequency trigger like patient.state.changed, that means one webhook call or email per event, one per patient. Across many patients, that can be dozens of deliveries in a short window — rarely what you want for email, and easy to mistake for flooding on a webhook pointed at a chat tool. Digest batching collects those deliveries and sends them as one summary, once a day, at a time of day you choose. In the Console each subscribed trigger has Send immediately or Send at . In the SDK the same choice is digest_schedule on create or update. patient.state.changed is the trigger we recommend batching; the Console defaults it that way when you subscribe. Every other currently available trigger is fine to leave on immediate delivery. That is a starting point, not a hard rule. Digest deliveries are not instant: they sit until the next scheduled batch. Expect the first one on the same day you enable it only if that time of day has not already passed. time_of_day must land on a :00 or :30 boundary (the Console picker already does this).

Create a destination

Full parameters, email destinations, digest schedule, rotate, and disable are in the SDK reference.