Skip to main content

Welcome a new user with an in-app message

Section: DOC-CP-notifications-administration#manage-workflows-subscribers-and-providers.

After a person finishes signing up, leave a welcome message they can find when they return to your application. Prepare one template, enroll that person as a notification recipient, send the welcome after signup succeeds and confirm it appears in their inbox. Start with in-app delivery; it needs no external email or push account.

Before you start​

Section: DOC-CP-notifications-administration#get-started.

Have a backend credential, one authenticated application user and the completed signup event that should trigger the welcome. Step 4 connects the message to the user’s inbox. Your application must authorize who can configure or send notifications: these management calls accept a verified key or configured standalone JWT without a separate administrator-role check.

Keep configuration and sending in the backend. Subscriber reads, updates and deletion select the user through authentication; /manage/ does not grant access to every user. The examples below use user-1 for one controlled application user.

Confirm which notification environment your account edits. These calls can change production directly; separate development and production notification environments are account-dependent.

1. Prepare the welcome message​

Section: DOC-CP-notifications-administration#workflows.

Create a workflow using manage/create-workflow. This existing in-app definition welcomes a coaching-app user; change its wording for your application while retaining the provider’s supported structure:

{
  "workflow": {
    "name": "Welcome Notification",
    "description": "Sent when a user completes onboarding",
    "__source": "editor",
    "steps": [
      {
        "name": "In-App Step",
        "type": "in_app",
        "controlValues": {
          "body": "Welcome to your health coaching journey!"
        }
      }
    ]
  }
}

Reference: Create a notification workflow · Request fields.

The response returns the stored workflow definition. Save the workflow/trigger identifier you will send; use list-workflows if you need to discover its valid identifier. Workflow definitions are opaque provider JSON—the Travila API passes them through rather than defining their delivery-step schema.

The template in this recipe contains its welcome text directly, so its send request does not need message variables.

2. Enroll the same application user​

Section: DOC-CP-notifications-administration#subscriber-management.

A subscriber is the notification record for your application user. Use manage/get-subscriber, authenticated as user-1, to check whether it already exists. This read takes {}; a backend selects the user with permitted X-On-Behalf-Of, not a user ID in the body. Push registration may already have created the record.

For a new recipient, call manage/create-subscriber with your application’s user identity:

{
  "subscriberId": "user-1"
}

Reference: Create a notification subscriber · Request fields.

Keep using user-1 when sending and when that person opens the inbox. The returned novuSubscriberId is an opaque provider reference, not a replacement for your application user ID. If creation’s response is lost, inspect the same user’s subscriber before trying to enroll them again.

3. Send after signup succeeds​

Section: DOC-CP-notifications-administration#send-welcome.

Once your application has confirmed signup, trigger the prepared welcome from your backend. Replace the sample workflow identifier with the one saved in step 1; the recipient must be the user enrolled in step 2.

curl -X POST https://api.travila.ai/api/v1/notifications/manage/send \
  -H "X-API-Key: sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
  "workflowId": "welcome-notification",
  "userId": "user-1",
  "payload": {}
}'

Reference: Send a notification to a user · Request fields.

Inspect acknowledged, the returned transactionId and any errors. Save that transaction with the application’s signup event. Descriptive status text such as processed means accepted for processing, not delivered.

A lost response does not prove that sending failed. Reconcile the original send before issuing a replacement; an optional caller-supplied transaction ID requires a qualified retry contract. Use the sending recipe and send reference for those boundaries.

4. Confirm the person can read the welcome​

Section: DOC-CP-notifications-administration#delivery-status.

Sign in as the same controlled user and load their inbox. Confirm the welcome appears, then open or mark it read and reopen the app to check the saved state. The feature is complete when the intended person can find the welcome—not when the trigger request returns successfully.

If the message is missing, use get-delivery-status with the saved transaction ID. Check the configured in-app step, the selected recipient and their preferences before sending another message.

For several missing notices, inspect a bounded window through notification activity. Use its filter contract and keep successful recipients usable while investigating.

Change the welcome without dropping other delivery steps​

Section: DOC-CP-notifications-administration#update-a-workflow.

Read the current workflow, change its wording, then submit the complete definition. The supplied definition replaces the stored one; retain every step your application still needs. Send it to a controlled user and verify the new message.

Where your account supports separate notification environments, inspect pending changes and promote the selected change after that test. Bulk promotion can partially succeed; omitting changeIds or sending an empty list selects all pending changes. Inspect each result and recover failed changes individually before treating the rollout as complete.

If you retire a template, stop triggering it before deleting it. Deletion does not cancel notices already in flight; cancel a pending send separately using its transaction.

Variant: add email or push after the inbox works​

Section: DOC-CP-notifications-administration#provider-configuration.

Obtain credentials for the extra delivery channel and configure that provider. Add its supported step to the complete workflow. Email needs the recipient’s address; push needs a registered device. Update contact details through the subscriber-data operation, then send a controlled welcome and verify each intended channel.

After changing credentials, test delivery to an already enrolled user. Follow provider configuration outcomes if configuration fails; a status read alone does not prove arrival.

Remove enrollment when the person leaves your application​

Section: DOC-CP-notifications-administration#delete-the-callers-subscriber.

Request subscriber deletion while authenticated as the departing user, then read back that subscriber to confirm the outcome. Use the subscriber deletion outcome contract when the result is absent or uncertain; confirm the read-back before reporting cleanup complete.

Removing this enrollment does not erase the application’s user record, every queued notice or external copy. Track those account-cleanup actions separately. For temporary channel choices or device sign-out, use preferences or device removal instead.

Document ID: DOC-CP-notifications-administration. Section identities and revisions.