Integrate WhatsApp Business API into Your Mobile App

Integrate WhatsApp Business API into Your Mobile App

We integrate WhatsApp Cloud API into mobile applications — from server logic to user interface. This is not about installing the WhatsApp Business App on a phone, but connecting to Meta's Cloud API with pre-approved templates, webhooks, and business account verification. Our team has 5+ years of experience: hundreds of successful integrations, handling up to 500 messages per second, with an average response time under 200 ms.

Typical scenario: a client wants to send order status notifications via WhatsApp and receive incoming messages from users. Without proper architecture, you risk getting your account blocked due to Meta policy violations. We help avoid this, saving up to 70% on bulk messaging compared to SMS.

How WhatsApp Cloud API Integration Works

Meta moved the API to the cloud — no need to host your own server. Sending a message is done via a POST request to the Graph API:

POST https://graph.facebook.com/v19.0/{PHONE_NUMBER_ID}/messages
Authorization: Bearer {ACCESS_TOKEN}
Content-Type: application/json

{
  "messaging_product": "whatsapp",
  "to": "380991234567",
  "type": "template",
  "template": {
    "name": "order_shipped",
    "language": { "code": "ru" },
    "components": [
      {
        "type": "body",
        "parameters": [
          { "type": "text", "text": "Ivan" },
          { "type": "text", "text": "#98765" },
          { "type": "text", "text": "today from 14:00 to 18:00" }
        ]
      }
    ]
  }
}

Templates (template) are mandatory for initial outbound messages. Free-form text can only be sent within 24 hours after the user's last message (service window). Each template is reviewed by Meta and typically approved in 1–3 business days. We ensure all templates pass moderation on the first try if policies are followed.

Template Categories and Restrictions

Marketing templates require explicit user consent. Sending without opt-in violates Meta policy and risks account suspension. We always implement a consent collection mechanism directly in the app.

Cloud API vs On-Premises: Which to Choose?

Cloud API launches 3 times faster than On-Premises due to no need for own infrastructure. For most projects, we recommend Cloud API.

How to Set Up Webhooks for Incoming Messages?

Webhooks (callbacks) are key to receiving user messages and delivery statuses. Setup involves these steps:

1. Create an endpoint on your server that accepts POST requests.
2. Register the URL in Meta Developer Console.
3. Handle the GET verification request (hub.challenge).
4. Set up processing of incoming messages and statuses.

The backend receives a POST like:

// Incoming message from user
{
  "entry": [{
    "changes": [{
      "value": {
        "messages": [{
          "from": "380991234567",
          "type": "text",
          "text": { "body": "When will delivery happen?" },
          "timestamp": "1711440000"
        }]
      }
    }]
  }]
}

// Delivery status of outbound message
{
  "statuses": [{
    "id": "wamid.XXXXX",
    "status": "delivered",
    "timestamp": "1711440060",
    "recipient_id": "380991234567"
  }]
}

Important: the endpoint must respond to POST in under 5 seconds — otherwise Meta will retry and eventually deactivate the webhook. We design the endpoint with asynchronous processing to meet the timeout. According to WhatsApp Cloud API documentation, the timeout must not exceed 5 seconds.

Why Is the 24-Hour Window Critical?

WhatsApp Cloud API allows sending free-form messages only within 24 hours after the user's last incoming message. After that window, only template messages can be sent. If this is ignored, the user won't get a timely response, degrading the customer experience. The mobile app should display the window status and prompt the operator to choose a template if the window is closed.

// iOS — loading conversation history
struct WhatsAppConversation: Identifiable, Decodable {
    let id: String
    let contactPhone: String
    let contactName: String?
    let lastMessage: WhatsAppMessage
    let unreadCount: Int
    let windowExpiresAt: Date? // 24-hour window
}

// Displaying window status
var isWithinServiceWindow: Bool {
    guard let expires = windowExpiresAt else { return false }
    return Date() < expires
}

If isWithinServiceWindow == false — the UI should show a warning that free-form messaging is not possible, and suggest choosing a template.

Business Account Verification

WhatsApp Business API requires a verified Business Manager in Meta. The process: create Meta Business Manager → verify business (documents) → create WhatsApp Business Account → get a phone number. The number cannot be used simultaneously in WhatsApp Business App — only in API.

Verification takes 5 to 14 days. This is a blocking step — development can proceed in parallel using the test sandbox (limited set of numbers). We help prepare documents in advance to speed up the process. Using WhatsApp instead of SMS can save up to 70% on bulk messaging.

What's Included in the Work?

• Requirements analysis and integration design
• Creating and registering message templates in Meta
• Developing a server-side webhook handler from scratch or integrating with existing backend
• Building mobile UI for operator chat with service window support
• Configuring code signing, push notifications for iOS/Android
• Integration with App Store Connect and Google Play Console
• API usage documentation and access transfer
• Testing in sandbox and production launch

Estimated Timelines

WhatsApp Cloud API integration, template creation and registration, webhook handler, mobile dialog UI with service window support — 8–12 working days (excluding Meta business account verification time). Cost is calculated individually based on project complexity.

Request a consultation on WhatsApp Business API integration — contact us to evaluate your project.

Push Notifications in Mobile App: APNs, FCM, Segmentation, Rich Push

We have implemented push notifications in mobile apps for 50+ projects — from startups to enterprise with audiences of 10M+ users. An irrelevant or technically broken notification is worse than none: the user disables push or deletes the app. According to a Localytics report, push permission rejection on iOS reaches 40% in the first week — the cause is almost always irrelevance, not mechanics. Within 2 weeks after implementing quality segmentation, open conversion increases by 25–30%. Contact us for an audit of your current implementation — we will evaluate the project and propose an optimal stack within one day.

How the Infrastructure Works: APNs and FCM

APNs is the only delivery channel on iOS. Everything else (OneSignal, Braze, Airship) is a wrapper on top of it. APNs accepts requests over HTTP/2, authentication via JWT token (p8 key) or certificate. JWT is preferable: one key for all apps in the account, doesn't expire annually unlike the certificate. For more details, see the official documentation.

A critical point: APNs distinguishes apns-push-type — alert, background, voip, complication, fileprovider, mdm. An incorrect type on iOS 13+ causes background notifications not to wake the app. We've seen projects where content-available: 1 was sent without apns-push-type: background — the app didn't receive silent push on some devices, and the team spent a month looking for an 'app bug'.

FCM on Android works through Google Play Services. For devices without GMS (Huawei, part of the Chinese market), Huawei Push Kit or a direct WebSocket is needed — a separate task. FCM supports data messages (handled in onMessageReceived) and notification messages (the system displays automatically if the app is in the background). Mixing them requires caution: if the notification block has a click_action but the deep link is not registered in the app, tapping the notification simply opens the main screen without navigation.

Why Segmentation Is the Foundation of Effective Push Notifications?

Sending to everyone indiscriminately quickly exhausts user loyalty. Personalized messages are clicked 3 times more often than bulk ones, and proper segmentation reduces churn by 25% (on one project it brought significant additional revenue per quarter). The cost of setting up segmentation in OneSignal or a custom backend depends on the complexity of filters.

Proper segmentation is built on several levels.

Topics are for broad categories: 'new promotions', 'order status updates'. User subscribes via FirebaseMessaging.getInstance().subscribeToTopic("orders"). Simple, but no flexible filtering.

Attribute-based segments — via OneSignal, Braze, or custom backend. We store in the user profile: language, device type, last activity, LTV segment. Notification goes only to those with last_active < 7_days and plan = premium. OneSignal allows building such filters in the interface without code.

Personalized — by specific device_token. It's important to store tokens correctly: the token updates on app reinstall, restoration from backup on a new phone, or resetting settings. On iOS, use UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, save to backend on every launch, not just the first. Otherwise, after 3 months 30% of tokens in the database are outdated.

What Is Rich Push and How Does It Boost Conversion?

A standard notification with title and text is clicked less often than a rich push with image and action buttons — by 3 times. But implementing rich push is a separate task on each platform.

On iOS, rich content requires UNNotificationServiceExtension (to modify payload) and UNNotificationContentExtension (custom UI). The extension runs in a separate process with limited time and memory. If the extension crashes or exceeds the timeout, the system shows the original payload without media. A typical mistake is trying to load an image over HTTP (not HTTPS): ATS blocks the request, the extension silently fails, and the user sees a notification without an image.

On Android with API 26+, notifications are tied to NotificationChannel. If the channel is created with IMPORTANCE_LOW, sound and vibration are unavailable. Different notification types (transactional, marketing) should be in different channels so the user can disable marketing without losing order notifications. BigPictureStyle, MessagingStyle, InboxStyle are templates for expanded notifications. MessagingStyle with Person and avatars is the best choice for chats.

How to Track Delivery and Conversion of Push Notifications?

Sending a notification is half the work. It's important to know: was it delivered, opened, and did it lead to a target action.

FCM returns a MessageId on send, but does not guarantee a delivery callback — by design. For open tracking, custom logic is needed: on notification tap in onMessageReceived or via getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), send an event to analytics with notification_id.

OneSignal provides built-in delivery and CTR analytics. For more detailed analysis — integrate with Amplitude or Mixpanel via webhook on open events. The budget for such a dashboard varies depending on event volume.

How We Implement Push Notifications: Typical Process

1. Audit current implementation — check token storage, update handling, notification types.
2. Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
3. Implementation — write registration code, inbound handling, rich push, deep linking.
4. Testing — send test campaigns, verify delivery on different devices, simulators, regions.
5. Monitoring and analytics — set up dashboard, open and conversion events.
6. Documentation and training — hand over operational materials to the team.

Typical stack: FCM + APNs at transport level, OneSignal or Firebase Notifications Composer for segmentation, custom backend for personalized event-based notifications. For large apps with >1M users, OneSignal has pricing limits — then we use Braze or a custom implementation on AWS SNS.

Timelines depend on complexity: basic FCM+APNs integration with transactional notifications — 1–2 weeks. A full system with segmentation, rich push, analytics, and A/B testing — 4–8 weeks. Order an audit of your current push infrastructure or get a consultation on implementing push notifications in your mobile app — we will contact you within a day and provide an accurate estimate.