The nudge® API opens up powerful ways to integrate push notification messaging directly into your own systems and workflows. This article gives a high-level overview of the main patterns we've seen partners and clients use successfully.

For the technical details behind each of these patterns, see the Preliminary API Integration Instructions article and the detailed API reference.

Which pattern should I use?

For most integrations, we recommend starting with Pattern 1: Segment management. Letting nudge handle delivery orchestration — rather than building that logic into your own system — consistently produces better engagement outcomes and a simpler integration. Pattern 2 is the right choice when your use case genuinely requires real-time, event-driven delivery.

If you're not sure which approach fits your situation, reach out to us at support@larky.com and we'll help you think it through.

Pattern 1: Segment management

The Segment API endpoints — including the /Segment/Members/ endpoints used to populate those segments — let you programmatically create and manage audiences on the nudge platform. In this pattern, the financial institution creates and manages campaigns and their message templates manually in the nudge portal — but instead of building audience lists by hand, those campaigns target segments that your system populates automatically.

Once a campaign is set up and pointed at an API-managed segment, nudge's backend takes over all messaging orchestration. That includes queuing messages, optimizing delivery timing, and applying capping rules to ensure account holders aren't over-messaged. Your system's job is simply to keep segment membership current; nudge handles the rest.

It's a clean division of responsibility: your platform handles the data and audience logic, nudge handles delivery orchestration, and the FI retains full control over messaging content and campaigns. We've consistently found that this approach leads to higher engagement rates — because nudge's orchestration engine is purpose-built to maximize message effectiveness while protecting the account holder's notification experience.

Common use cases include:

• Evergreen campaigns — campaigns that remain open indefinitely and simply watch for new segment members each time the API is called to refresh the segment. As new account holders qualify, they're automatically picked up for messaging without any manual intervention.
• Surfacing audiences derived from core banking data (e.g. members with high-interest loans, inactive debit card holders)
• Enabling FI clients to act on data insights they already have, without manual list uploads

Pattern 2: TriggerNudge — direct push notification delivery

The TriggerNudge endpoint lets your system send a push notification directly to a specific app user — or a group of users — at the exact moment your system determines it's time. This pattern is most appropriate when real-time, event-driven delivery is genuinely required — for example, when a time-sensitive trigger in your system needs to reach a specific account holder immediately.

Your system takes over orchestration: it decides when to fire the notification and who receives it. Nudge's capping rules may still prevent delivery to protect account holders from over-messaging, but this can be overridden through parameters in the API payload when your use case warrants it.

A campaign needs to exist in the nudge portal first. That campaign holds the message content that will be sent and serves as an analytics container — impressions and taps for nudges sent via the API are organized and reported at the campaign level. A campaign can contain multiple nudges, which allows related messages to be grouped together for reporting purposes.

For clients who want full control over messaging, the campaign content is sent exactly as configured in the portal — no additional payload content required. If personalization is desired, the API caller can optionally override that content through the payload, allowing the message title, body, and destination URL to be dynamically tailored to the specific account holder.

Common use cases include:

• Transactional alerts triggered by core banking events (e.g. large transaction, low balance notification)
• Time-sensitive operational messages where immediate delivery is required
• Scenarios where the timing and recipient of the message must be driven by your system in real time

Choosing the right pattern

These two patterns aren't mutually exclusive — some integrations will use both. When in doubt, start with the Segment API.

API Reference

The full API documentation is available here.