Appearance
Meta API assessment
What Meta's official APIs can actually do for QRSETU — verified against live Meta documentation on 2026-08-21, not recalled. Every capability is tagged AVAILABLE NOW / REQUIRES APPROVAL-OR-CONFIG / UNSUPPORTED (no API), and the handful of facts that could not be confirmed on a first-party page are tagged UNVERIFIED rather than asserted. The strategic decision this page supports: integrate Meta directly — no WATI/MSG91/BSP dependency (ADR-0029).
DOC-MIGRATION HAZARD
Meta is mid-migration from developers.facebook.com/docs/whatsapp/… to developers.facebook.com/documentation/business-messaging/whatsapp/…. Several old sub-pages now 404 while their parents resolve. Re-verify any cached URL before citing it.
1 · The APIs QRSETU uses, and for what
| API | What it provides | QRSETU use |
|---|---|---|
Cloud API (POST /{phone_number_id}/messages) | sending: templates, free-form (24h window), media, interactive (buttons, lists, CTA-URL, Flows), reactions, location. Hosted by Meta — On-Premises API is dead (final version expired 2025-10-23) | every outbound message, via the one dispatcher EF |
| Business Management API (WABA node) | template CRUD + review submission, phone-number management, analytics / pricing_analytics / template_analytics, subscribed apps | manage-communication EF + the usage/cost ingest |
Graph Webhooks (whatsapp_business_account object) | message status, inbound messages, template status/quality/category, number quality, account + capability updates | the whatsapp-webhook EF — the entire receive path |
India Payments API (order_details messages) | in-chat payment collection, INR only, PG deep integration with Razorpay (also PayU/Billdesk/Zaakpay), UPI capped ₹5,00,000 | future Model-B option — see §7 |
| Embedded Signup + Business Integration System User tokens | onboarding OTHER businesses' WABAs under our app | the P3+ tenant-sender programme only |
| WhatsApp Flows · Business Calling API | in-chat forms; VoIP on the business number (business-initiated calling available in India, needs the 2,000 tier) | noted as future capabilities, no R1 use |
2 · Access model — why Phase 1 needs no App Review
- Own WABA = Standard Access. Meta's own App Review page: "if you are using the API for yourself as a Direct Developer, you do not need Advanced access or app review." QRSETU sending from its own numbers is buildable immediately. AVAILABLE NOW.
- Server credential = a System User access token (Business Settings → System Users; 60-day or never-expiring — exact durations UNVERIFIED on current page text), with
whatsapp_business_messaging+whatsapp_business_management+business_management. Never a user token in a server. - Advanced Access + App Review + business verification are required only when other businesses grant our app access to their WABAs — the Tech Provider path (§6). REQUIRES APPROVAL.
- Development mode: an auto-created test WABA + test number, no payment method needed, recipient allowlist (limit of 5 — VERIFIED-THIRD-PARTY only).
3 · Use-case coverage
| QRSETU use case | Meta capability | Status | Phase |
|---|---|---|---|
| Order confirmation (buyer) | UTILITY template; free if the buyer messaged us within 24h | AVAILABLE NOW | P1 |
| Payment confirmation / receipt | UTILITY template | AVAILABLE NOW | P1 |
| Order status updates (ready / collected) | UTILITY template | AVAILABLE NOW | P1 |
| Merchant notifications (new order, payout, quality alerts) | UTILITY template | AVAILABLE NOW | P1 |
| Signup / onboarding messages | UTILITY template — keep it factual: ANY promotional content forces MARKETING categorization | AVAILABLE NOW | P1–P2 |
| Setu Card communication (publish confirmation, activity digest) | UTILITY (digest content must stay non-promotional) | AVAILABLE NOW | P2 |
| Promotional / campaign messages | MARKETING template; consent required; Meta's per-user frequency cap applies (§5) | AVAILABLE NOW (with policy constraints) | P3 |
| OTP / authentication | AUTHENTICATION template (fixed body, OTP ≤15 chars, TTL default 10 min, configurable 30–900 s; one-tap/zero-tap Android-only) — but Supabase Auth cannot use our WABA natively (§7), and QRSETU's auth is email OTP by ADR-0008 | AVAILABLE NOW at Meta / bespoke flow at Supabase | future |
| Consumer notifications (order code, collect reminders) | UTILITY template to orders.buyer_phone — anonymous-first compatible, no app install needed | AVAILABLE NOW | P1–P2 |
| Merchant/enterprise sending under their own brand/number | Tech Provider + Embedded Signup + per-tenant WABAs | REQUIRES APPROVAL (programme, not a feature) | P3+ |
| In-chat collection of payment | India Payments API with Razorpay PG config | REQUIRES CONFIG + one UNVERIFIED compatibility question (§7) | decision |
| Two-way conversational support | inbound messages webhook + free-form replies inside the 24h window | AVAILABLE NOW (bridge to the chat domain: future) | P3+ |
4 · Template management — the facts that shape the registry
- Endpoints: create
POST /{waba_id}/message_templates, list/read, editPOST /{template_id}, delete by name (deletes all languages of that name). AVAILABLE NOW. - No versioning exists. Templates are keyed name + language; an edit mutates in place and re-enters review. A breaking change is therefore a new name — the Setu Card manifest discipline (supersede, never edit) imposed by the provider.
- Categories:
MARKETING/UTILITY/AUTHENTICATION. Meta recategorizes automatically, at review and recurringly post-approval (1-day notice, 60-day appeal window,template_category_updatewebhook). Mixed content ("order update + promo") is forced MARKETING. A recategorization changes the price of every send — the registry must mirror, never assume. - Review: automated + manual, up to 24h. Rejection reasons are enumerated (
PROMOTIONAL,TAG_CONTENT_MISMATCH,INVALID_FORMAT,SCAM,ABUSIVE_CONTENT, …); appeal with sample supported. Status enum (webhook-authoritative):PENDING · APPROVED · REJECTED · PAUSED · DISABLED · IN_APPEAL · FLAGGED · LIMIT_EXCEEDED · LOCKED · …. - Edit budget on approved templates: reported as 10 edits / 30 days, 1 / 24h — UNVERIFIED on a first-party page (Meta's page would not render; consistent across BSP docs).
- Utility template library exists: pre-categorized templates (delivery updates, payment reminders); unmodified library templates skip content review. AVAILABLE NOW — the cheap way to bootstrap P1.
- Limits: 250 templates per unverified WABA (6,000 verified portfolio); creation capped 100/WABA/hour;
parameter_formatpositional or named (named is what the registry stores).
5 · Sending limits, quality, and policy — the constraints the dispatcher enforces
- Messaging limit ladder (unique recipients per rolling 24h, business-initiated outside the window): 250 unverified → 2,000 via business verification (or 2,000 delivered high-quality templated messages in 30 days) → 10,000 → 100,000 → unlimited, auto-scaled every ~6h when quality is high AND ≥50% of the current limit was used in the last 7 days.
- Hard rate facts: 80 messages/sec default throughput (auto-upgradable to 1,000); 1 message per 6 seconds per recipient (pair limit); Business Management API 200 calls/hour/app/WABA (5,000 once a number is registered).
- Quality enforcement ladder: number quality GREEN/YELLOW/RED (7-day recipient feedback) → Flagged blocks tier upgrades, 7 unrecovered days drops a tier. Template-level quality pausing: 3h first, 6h second, permanently disabled third.
- Per-user marketing caps are live in India: a dynamic, unpublished, per-USER cap shared across ALL businesses — a marketing send can fail (error
131049) because other businesses exhausted the user's budget. Back off ≥24h; never timer-retry. (The US marketing pause — no marketing templates to +1 numbers since 2025-04-01 — is still active; India is unaffected but it is proof Meta will suspend a whole category per country.) - Opt-in policy is channel-agnostic: any method, but it must name the business and clearly state what the person is opting into; opt-outs must be honoured per category. QRSETU's consent ledger is the implementation (see data model).
- Prohibited categories (Business Messaging Policy) matter for a multi-vertical platform: drugs, weapons, gambling, adult, MLM-style schemes, dating, and several fin-services (payday loans, debt collection…). This maps onto the existing
compliance_profilereasoning — a restricted vertical must never be onboarded into marketing sends. - TTLs: authentication default 10 min (30–900 s); utility default 30 d (30 s–12 h configurable band noted as 30–43,200 s); marketing default 30 d.
6 · Pricing, billing and usage — what can and cannot be automated
Pricing model (current): per-message since 2025-07-01 (conversation pricing is formally deprecated). Charged when a template message is delivered: MARKETING always; UTILITY only outside an open 24h customer-service window (inside = free); AUTHENTICATION charged. Service (user-initiated) conversations are free. Free-entry-point windows (Click-to-WhatsApp ads / FB Page CTA): 72h, all messages free.
India specifics:
- Rates (Meta list, ex-GST, +18% GST): marketing ~₹0.86 (raised 2026-01-01), utility ~₹0.115, authentication ~₹0.115 — UNVERIFIED to the paisa (the official rate card is behind a JS download at business.whatsapp.com/products/platform-pricing#rates; values are the consistent cross-source consensus). Volume tiers exist for utility/auth only.
- ⚠ INR migration is a hard deadline: WABAs billed to India must be INR-billed by 2026-12-31; from 2027-01-01 Meta stops delivering messages for non-INR WABAs. Create the production WABA INR-billed from day one.
Billing automation: UNSUPPORTED — verified plainly. There is no public API to (a) add or manage payment methods, (b) top-up/recharge any balance, or (c) fetch invoices. Payment method (credit/debit card, postpaid) and invoices live only in Meta's Billing Hub UI; monthly invoicing exists but requires an approved Meta credit line. A "recharge/top-up balance" screen is a BSP product concept, not a Meta capability — the Admin Hub ships a billing runbook, not billing UI.
Usage and cost reporting: AVAILABLE NOW, on the WABA node:
pricing_analytics— the endpoint that matters: per-message VOLUME + COST, granularity half-hour/day/month, dimensioned by phone number, country, pricing category, pricing type (regular / free entry point / free customer service), tier. Cost in the WABA's currency.analytics— sent/delivered volumes.template_analytics— per-template sent/delivered/read + button clicks +cost_per_delivered(requires one-time opt-in).conversation_analytics— legacy, lookback cut to 1 year; do not build on it.- What is still NOT obtainable programmatically: invoiced totals, GST lines, credits/adjustments.
pricing_analyticsCOST is Meta's computed message cost — the reconciliation input, not the bill.
7 · Gaps, and the honest alternative for each
| Gap | Status | Alternative |
|---|---|---|
| Billing automation (payment methods, invoices, top-up) | UNSUPPORTED | ops runbook + pricing_analytics reconciliation; alert on spend anomaly from our own ledger |
| Prepaid balance / wallet | UNSUPPORTED (postpaid card or approved credit line only) | if merchant-facing "communication credits" are ever sold, the wallet is a QRSETU ledger construct on top of our postpaid Meta account — never a Meta object |
| Supabase-native WhatsApp OTP from our own WABA | UNSUPPORTED (Supabase phone providers: Twilio/Twilio Verify/MessageBird/Vonage; WhatsApp only via Twilio) | auth stays email OTP (ADR-0008); if WhatsApp OTP is ever wanted, it is a bespoke EF flow with AUTHENTICATION templates + a custom verify path — a design of its own, not a toggle |
| Per-merchant sender branding in R1 | REQUIRES APPROVAL later (Tech Provider: business verification + Advanced Access review + Embedded Signup v4 — v2 is deprecated 2026-10-15) — and ⚠ Tech Providers get NO credit line: onboarded customers attach their own card and pay Meta directly | R1: QRSETU is the single sender of record; merchant identity travels in template variables and ledger attribution. Full four-constraint assessment, including the contractual WABA-per-client requirement and the one shape that delivers customer branding on a QRSETU bill: the tenant model · ADR-0030 |
| Reselling messaging at a wholesale margin | UNSUPPORTED as an economic model — volume discounts accrue per business portfolio, reset monthly, and cover utility/authentication only, never marketing. With each customer on their own portfolio, volume never pools | price the service, not the message. A credit's margin is a platform fee, not arbitrage |
| WhatsApp in-chat payments feeding Model B | REQUIRES CONFIG, plus one open question: Meta documents Razorpay PG deep integration (UPI + cards, refunds, status webhooks, payment_configuration_update), but nothing documents Razorpay Route/split settlement riding a WhatsApp-initiated payment — UNVERIFIED | do not assume Model-B compatibility; verify transfers support on WhatsApp-originated Razorpay payments with Razorpay before any design (QRS-805) |
| Marketing as a reliable growth channel | constrained by design (per-user caps, quality pausing, ~₹0.86+GST per send) | lean on free surfaces: utility flows inside service windows, free-entry-point (Click-to-WhatsApp) conversations, and the platform's own in-app proactive surfaces |
8 · Now vs later
| Now (P1–P2) | Later (P3+) | Not unless something changes |
|---|---|---|
| Own WABA + 1 number, Standard Access, System User token | Marketing campaigns on the consent ledger | Prepaid/recharge UI (no API) |
| Transactional UTILITY templates on the money path | Merchant self-serve campaigns (entitlement-gated) | WhatsApp OTP as the primary auth (email OTP is decided) |
| Webhook EF + event ledger + status derivation | WhatsApp Flows (booking/feedback forms), Calling API | A second renderer of billing state (Meta's Billing Hub is the only truth) |
| Template registry + status/quality webhooks | Tech Provider + Embedded Signup for tenant WABAs | |
pricing_analytics ingest + usage rollups | India in-chat payments (pending the Route question) | |
| Business verification → the 2,000 tier | Official Business Account (blue check) application |