AI-Assisted SDK Integration

Use this workflow to integrate Reteno into an existing app. Read the matching SDK documentation for implementation details and current requirements. No integration skill needs to be installed.

1. Inspect

1. Read the repository instructions and inspect existing changes. Use a working branch and preserve unrelated work. Commit, push, or deploy only when requested.

2. Detect the app root, framework, target platforms, and existing Reteno or notification setup. A cross-platform app's ios/ or android/ directory does not make it a native app. Start with the highest-level framework:

   Detected app	SDK documentation
   Native iOS	iOS setup
   Native Android	Android setup
   React Native	React Native SDK
   Flutter	Flutter SDK
   Expo	Expo SDK
   Cordova	Cordova SDK
   Ionic	Ionic SDK
   Unity	Unity SDK

   Follow the framework guide's links for each target platform. If the detected runtime or requested feature is not covered, report the documentation gap before applying another framework's instructions. Append .md to documentation URLs for plain Markdown; use the documentation index to find additional pages.

3. Identify the target Reteno account and mobile app, app identifiers, SDK access key, push provider configuration, and test device. Ask only for missing information. Confirm that Firebase configuration and signing match the app, and that its token route matches the Reteno app's FCM or APNs configuration. Keep credentials in the project's local or build configuration; redact keys and full tokens from logs and reports.

4. Check available build, device, and Reteno tools. Reteno MCP can inspect contacts and validate a test push. It runs separately from the mobile SDK and is available only if it is already connected in the agent environment — see Reteno MCP setup below. Discover available tools and their inputs. If a tool is unavailable, use the Reteno interface or ask the developer to perform the required action. Continue work that is not blocked.

2. Integrate

1. Follow the selected SDK guide and release notes. Reuse the project's dependency manager and existing integration. Explain any required change to app identifiers, push provider, signing, or supported OS versions before making it; obtain approval if the task does not already authorize that change.
2. Install and initialize the framework SDK once, then configure permissions, token handling, and notification callbacks for each target platform. Preserve existing handlers. Check for competing Firebase messaging services on Android and overwritten notification delegates on iOS. Configure iOS Notification Service Extension and App Groups as required by the selected guide.
3. Keep changes reproducible. For generated native projects, put configuration in the source config, plugin, or hook so it survives regeneration or sync. Follow Expo's documented initialization path and use a development build. Respect Cordova or Ionic native-bridge readiness. Do not replace the framework integration with an additional native SDK setup unless its guide requires it.
4. Build and launch each target platform, enable notification permission, and inspect runtime logs. Resolve integration errors without disabling existing features or checks. Identify unrelated build failures separately. If device automation is unavailable, ask the developer to perform the action and continue from the result.

3. Verify

For each target platform, complete these checks using Reteno MCP, the Reteno interface, and device or SDK logs:

1. Registration: locate the contact and device created by this app. Match the device ID or token to the running build; app names alone may identify unrelated test data. Confirm that mobilePushToken is present and its provider matches the Reteno app configuration.
2. Test push: confirm the intended test recipient and permission to send. Send only to that test device or contact, never to a broadcast audience. If the contact has multiple devices, use a device/token target where available and record the actual scope. Record the contact, device, message, and send/interaction identifiers needed to correlate the result.
3. Delivery: confirm that the notification appears on the device and check DELIVERED tracking. A successful send response alone does not prove delivery.
4. Opening: open the actual notification, manually if needed, and check CLICKED tracking for the same send. Do not call status-update APIs or fabricate SDK events to make validation pass.
5. Additional features: validate identification, custom events, in-app messages, deep links, or other features when included in the task. Report a feature that was not part of the task as not requested for this integration; see Feature-specific validation below for the wording to use.

If a status tool returns empty or stale data, check contact message history or SDK/network interaction logs for the same send. Record device observations and tracked statuses separately: a visible banner or tap does not by itself prove backend tracking. If evidence is unavailable, mark that check as unverified. For a failed send, use mobile push error codes. Diagnose the failed step before retrying; do not repeat unchanged sends or fixes indefinitely.

Reteno MCP setup

Reteno MCP must be connected in the same environment where the AI coding agent runs.

Reteno MCP is used for Reteno-side validation:

• contact lookup;
• mobilePushToken verification;
• token type validation;
• test push creation and sending when the capability is available and approved;
• DELIVERED / CLICKED status checks when the capability is available;
• feature-specific validation when the required MCP capabilities are available.

Reteno MCP is not part of the mobile app and is not configured inside the iOS or Android project.

The Reteno MCP server endpoint is:

https://mcp.reteno.com

MCP authentication uses Reteno OAuth login. Do not use a Reteno REST API key for MCP connection.

The connected AI agent acts with the permissions of the signed-in Reteno account. Make sure the account has access to the required Reteno organization, workspace, mobile app, contacts, messages, and validation tools.

Official Reteno MCP setup guides

Use the official Reteno setup guide that matches the AI coding agent environment:

Cursor direct MCP configuration

For Cursor, add the Reteno MCP server in Cursor MCP settings:

{
  "mcpServers": {
    "reteno": {
      "url": "https://mcp.reteno.com"
    }
  }
}

After saving the configuration, restart Cursor, connect to the Reteno server, sign in with the correct Reteno account, and grant access.

Verify MCP connection

Before SDK validation starts, ask the agent to verify the MCP connection.

Examples:

List the available Reteno MCP tools.

Are any MCP servers connected?

Expected result:

• Reteno MCP server is connected;
• Reteno MCP tools are visible;
• available and authorized MCP capabilities are discovered;
• the signed-in Reteno account has access to the selected Reteno organization, workspace, and app.

If Reteno MCP is not connected, Reteno-side validation cannot be completed.

Do not mark SDK integration as complete until Reteno MCP validation is completed or the MCP blocker is clearly documented.

If MCP cannot be connected

If Reteno MCP cannot be connected in the current AI agent environment:

• continue only with integration steps that are not blocked by MCP;
• do not mark the integration as complete;
• report MCP validation as blocked / pending;
• document which validation steps could not be completed;
• use another approved MCP-enabled environment if available;
• or ask the developer/admin to approve Reteno MCP access for the current environment.

Common causes:

• corporate agent environment blocks external MCP connections;
• third-party plugins/connectors are restricted;
• network access to Reteno is blocked;
• wrong Reteno account was authorized;
• Reteno account does not have required permissions;
• agent environment needs restart after plugin/MCP setup.

Shared validation expectations

Each platform runbook defines platform-specific validation details.

At minimum, for core mobile push integration, the agent must validate:

• contact creation;
• mobilePushToken assignment;
• token type validation;
• test push sending;
• DELIVERED status;
• CLICKED status;
• final report.

The agent must not mark the integration as complete until the required validation checks pass or a blocker is clearly documented.

Token type expectations

Expected token type depends on platform and selected Reteno app configuration:

The token assigned to the contact must match the token type configured for the selected Reteno mobile app.

Feature-specific validation

The agent must validate every Reteno SDK feature that it integrates, modifies, or is explicitly asked to verify.

Feature-specific validation may include:

• custom events;
• In-App messages;
• mobile-push + In-App;
• externalCustomerId;
• deeplinks;
• custom push data;
• READ status;
• action buttons.

If a feature was not part of the current integration task, report it as:

not requested for this integration

If a feature was part of the current integration task but could not be validated, report it as one of the following:

blocked
manual fallback required
missing MCP capability
unavailable test environment
unavailable Reteno UI / admin setup

Do not use the following wording for feature-specific checks:

• MVP;
• extended validation;
• optional;
• out of scope;
• out of MVP scope;
• included in scope;
• selected validation scope.

Use instead:

• core mobile push validation;
• feature-specific validation;
• part of the current integration task;
• not requested for this integration.

Final report expectations

Each platform runbook contains a platform-specific final report format.

At minimum, the final report should include:

• report type: Complete or Partial;
• overall status: Passed, Passed with warnings, Blocked, or Failed;
• platform detected;
• evidence used for platform detection;
• application;
• Git branch / working copy status;
• SDK version;
• files inspected;
• files changed;
• dependencies added or updated;
• SDK access key status;
• build/run result;
• test environment;
• local automation / manual fallback status;
• Reteno MCP connection;
• MCP capabilities used or missing;
• contact lookup result;
• mobilePushToken result;
• token type;
• test push result;
• DELIVERED result;
• CLICKED result;
• feature-specific validation checks;
• blockers;
• recommended next steps.

The report type must be Partial if build/run, runtime interaction, Reteno MCP validation, contact lookup, token verification, test push, DELIVERED, or CLICKED was skipped, blocked, or not verified.

Do not include secrets, SDK access keys, Firebase server credentials, APNs private keys, certificates, service account data, or full push tokens in the final report.

Use redacted values for sensitive identifiers when needed.

What belongs here and what belongs in a platform runbook

Keep on this page

This page should contain:

• navigation;
• published runbook links;
• high-level usage flow;
• Reteno MCP setup;
• shared validation expectations;
• shared final report expectations;
• publication scope notes.

Keep in platform runbooks

Each platform runbook should contain:

• platform-specific Quick Start Prompt;
• platform-specific Source of Truth;
• platform-specific Developer Preparation Checklist;
• platform-specific SDK integration workflow;
• platform-specific local automation fallback;
• platform-specific MCP validation details;
• platform-specific troubleshooting;
• platform-specific final report format.

Do not keep platform-specific SDK steps on this page.

For example, these belong in the iOS runbook, not on this page:

• AppDelegate / SwiftUI lifecycle setup;
• deviceTokenHandlingMode;
• Notification Service Extension;
• App Groups;
• APNs vs FCM token handling;
• iOS-specific troubleshooting;
• iOS-specific final report fields.

For example, these belong in the Android runbook, not on this page:

• Gradle setup;
• AndroidManifest setup;
• custom Application class;
• Firebase Messaging service;
• Android notification permission;
• notification channel setup;
• minSdkVersion approval rule;
• WorkManager / ANR troubleshooting;
• Android-specific final report fields.