feat(whatsapp): implement official WhatsApp Cloud API provider

[MeenalSinha]

Proposed Changes

• Implemented the concrete WhatsAppProvider class utilizing the Official WhatsApp Cloud API (Meta).
• Integrated message transmission logic that handles sending text messages directly via Meta's Graph API.
• Minimized reliance on third-party Business Solution Providers (BSPs) to ensure full platform control and cost-effectiveness.
• Ensured consistency with the BaseMessagingProvider abstraction for future service modularity.

Associated Issue

• This PR completes Phase 2 of the Generic IM Wrapper integration.

Architecture changes

• Added the provider implementation at care/messaging/providers/whatsapp.py.

Merge Checklist

• Provider successfully interacts with Meta Graph API.
• Update docs in /docs
• Linting Complete
• Environment variables registered (e.g., WHATSAPP_ACCESS_TOKEN).

Only PR's with test cases included and passing lint and test pipelines will be reviewed

@ohcnetwork/care-backend-maintainers @ohcnetwork/care-backend-admins

Summary by CodeRabbit

• New Features
  • Integrated WhatsApp messaging functionality into the platform.
  • Established a messaging infrastructure framework to support multiple messaging providers in future updates.

[coderabbitai]

Caution

Review failed

Pull request was closed or merged during review

📝 Walkthrough

Walkthrough

This pull request establishes a new messaging module for Django. It includes app configuration, an abstract base provider class for messaging integrations, and a concrete WhatsApp Graph API provider implementation with configuration validation and webhook handling.

Changes

Cohort / File(s)	Summary
App Configuration care/messaging/apps.py	Introduces MessagingConfig app configuration with lazy translation for verbose name.
Provider Infrastructure care/messaging/providers/base.py	Defines abstract base class BaseMessagingProvider with contract for send_message and handle_webhook methods.
WhatsApp Provider care/messaging/providers/whatsapp.py	Implements WhatsAppProvider with Graph API integration, credential validation, debug mode fallback, and webhook handler stub.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description addresses most required sections, though test coverage remains unchecked despite repository policy requiring it for review.	Add test cases and mark the 'Tests added/fixed' checkbox. Repository policy explicitly requires tests and passing pipelines for review eligibility.
Docstring Coverage	⚠️ Warning	Docstring coverage is 40.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title accurately reflects the main change: implementing a WhatsApp Cloud API provider as a concrete implementation of the messaging abstraction.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR introduces a new WhatsAppProvider class for sending messages via Meta's WhatsApp Cloud API as part of a phased Generic IM Wrapper integration. While the high-level structure is on the right track, the implementation has two critical P0 issues that will cause runtime failures before any message can be sent.

Key issues:

• Missing base class (care/messaging/providers/base.py does not exist) — the import at line 3 will raise an ImportError on module load. The BaseMessagingProvider is not defined anywhere in the repository.
• Undefined settings — settings.WHATSAPP_PHONE_NUMBER_ID and settings.WHATSAPP_ACCESS_TOKEN are not registered in any settings file; instantiating WhatsAppProvider() will raise AttributeError. The existing SnsBackend pattern of using getattr + ImproperlyConfigured should be followed, and the settings should be added to config/settings/base.py.
• No request timeout — the requests.post() call has no timeout, leaving the thread vulnerable to hanging indefinitely on slow or unresponsive upstream responses.
• Hardcoded API version (v17.0) — should be configurable to avoid a forced code change when Meta deprecates this version.
• No tests — the merge checklist explicitly states that only PRs with test cases are reviewed.

Confidence Score: 1/5

Not safe to merge — two P0 issues will cause ImportError and AttributeError before any message can be sent.

The PR cannot function at all in its current state: the base class it inherits from does not exist (causing an ImportError on import), and the Django settings it reads at instantiation time are not defined anywhere (causing an AttributeError). These are not theoretical concerns — they are guaranteed runtime failures. Tests are also missing, which is a stated requirement for review.

care/messaging/providers/whatsapp.py — the only changed file, but the missing base.py and missing settings registration in config/settings/base.py are equally blocking.

Important Files Changed

Filename	Overview
care/messaging/providers/whatsapp.py	New WhatsApp Cloud API provider — imports a non-existent BaseMessagingProvider, accesses undefined Django settings causing AttributeError at instantiation, has no request timeout, and no tests.

_{Reviews (1): Last reviewed commit: "feat(whatsapp): implement official Whats..." | Re-trigger Greptile}

[greptile-apps]

Undefined Django settings cause AttributeError at instantiation

Neither WHATSAPP_PHONE_NUMBER_ID nor WHATSAPP_ACCESS_TOKEN is defined in any settings file (config/settings/base.py, production.py, deployment.py, etc.). Direct attribute access on the settings object will raise AttributeError: 'Settings' object has no attribute 'WHATSAPP_ACCESS_TOKEN' as soon as WhatsAppProvider() is constructed.

The existing SnsBackend pattern uses getattr(settings, "SNS_ACCESS_KEY", None) and raises ImproperlyConfigured with a descriptive message when a required value is absent. This PR should follow the same approach:

1. Add WHATSAPP_PHONE_NUMBER_ID and WHATSAPP_ACCESS_TOKEN (defaulting to None) to config/settings/base.py.
2. Guard access in __init__ with getattr + ImproperlyConfigured, as SnsBackend does, rather than accessing the attributes directly.

[greptile-apps]

Hardcoded Graph API version v17.0

Meta regularly deprecates older Graph API versions. Hardcoding v17.0 directly in the URL means this will break when Meta sunsets that version without any code change triggering a visible warning. Consider making the version configurable via a setting (e.g., WHATSAPP_API_VERSION, defaulting to the current stable version) so it can be bumped without a code deploy.

[vigneshhari]

Please delete all existing MR's or you will be banned from contributing to care.