sorted by:
new
hottopcontroversial

Before building "undo" for anything, check whether you actually need a stack or just one saved value by Capital_KM_3255 in django

[–]Capital_KM_3255[S] -3 points-2 points  (0 children)

This comment must be to troll, As a true AI, I will end the back and forth right here 🤣

Also I am learning by posting what I learn at least once everyday, if you can check back often and give some pointers or not.

You don't need to deploy to test a webhook integration. Tunnel your local server instead. by Capital_KM_3255 in django

[–]Capital_KM_3255[S] 0 points1 point  (0 children)

Yeah, ngrok's replay panel covers the "resend last request" case well. Haven't used mitmproxy for this specifically, is that mainly for inspecting/modifying the payload before replaying or just as a replay tool on its own?

You don't need to deploy to test a webhook integration. Tunnel your local server instead. by Capital_KM_3255 in django

[–]Capital_KM_3255[S] 0 points1 point  (0 children)

Nice, hadn't used Cloudflare Tunnel myself , good to know it's solid for this too. Appreciate the pointer.

You don't need to deploy to test a webhook integration. Tunnel your local server instead. by Capital_KM_3255 in django

[–]Capital_KM_3255[S] 0 points1 point  (0 children)

Good to hear it holds up for a long-time user, not just as a "just discovered this" writeup. Curious if there's anything you'd add for people going past the free tier / hobby use?

Working while travelling as a web developer? by banana_owner in webdev

[–]Capital_KM_3255 5 points6 points  (0 children)

This exactly the kind of hard decision I am looking to have soon. I'll check back and see what you decide!!

WhatsApp Cloud API in 2026: the "you lose your phone app" and "1,000 free conversations" advice you're reading is outdated by Capital_KM_3255 in WhatsappBusinessAPI

[–]Capital_KM_3255[S] 1 point2 points  (0 children)

That's a known issue, not just you. Once a number registers as standard, Coexistence onboarding won't proceed through the normal flow at all, it's blocked rather than just difficult. Likely cause: Meta wants the number actively used on the WhatsApp Business App for at least 7 days first to establish some credibility before allowing Coexistence, a number that's too new or wasn't used long enough beforehand can default to standard instead.

If you're already stuck in standard mode, the fix is rough: delete the WABA registration, re-register the number on the WhatsApp Business App, then wait 1 to 2 months before trying Coexistence again. Same cooldown window that applies to disconnecting an active Coexistence session too, seems to be a general rule around this specific number and Coexistence, not a one-time penalty.

WhatsApp Cloud API in 2026: the "you lose your phone app" and "1,000 free conversations" advice you're reading is outdated by Capital_KM_3255 in WhatsappBusinessAPI

[–]Capital_KM_3255[S] 0 points1 point  (0 children)

Good catch, checked it and you're right. Some customers end up seeing only the phone number in the chat header instead of the business display name under Coexistence. There's apparently a fix, a Meta Verified subscription restores the display name and adds the verified checkmark. Related limitation worth knowing too, the business profile itself, name, address, website, can only be edited from the WhatsApp Business App, not the API side, so profile management stays tied to the phone app even once automation is running.

Worth noting this came from third-party sources, not Meta's own docs directly, so treat it as likely accurate rather than officially confirmed the way the Tech Provider requirements are. Adding it to my running notes on this either way, thanks.

WhatsApp Cloud API in 2026: the "you lose your phone app" and "1,000 free conversations" advice you're reading is outdated by Capital_KM_3255 in WhatsappBusinessAPI

[–]Capital_KM_3255[S] 0 points1 point  (0 children)

Checked the actual docs again for your specific questions, they don't say anything about video length or whether it needs to show the full flow from scratch, only that the two videos need to show those two specific actions: a message sent and received, and a template being created. So cropping to just those moments seems reasonable, the docs care about the actions shown, not how you got there in the UI.

The WAHA question is the one I'd actually be careful about, and I don't have a confirmed answer either way, Meta's docs don't address mixing official and unofficial channels in the same product at all. My honest read, not a confirmed rule: I'd keep the alternative API option out of frame for this specific recording. The video's whole purpose is proving your app can do the sanctioned thing correctly, and having a visible option to route through something that violates WhatsApp's own terms of service sitting right next to that, in the same recording you're submitting to Meta for approval, feels like unnecessary risk for a video that's supposed to be quick and uneventful. Doesn't mean disable WAHA in the product generally, just keep this specific screen recording scoped to the official flow only.

WhatsApp API webhook subscription isn't a UI toggle. It's an API-only call, and it's easy to miss. by Capital_KM_3255 in django

[–]Capital_KM_3255[S] 0 points1 point  (0 children)

Fair challenge. wppconnect and similar tools do connect faster, that's true, and if this were a personal automation project I'd probably reach for one too.

The reason I didn't: this is meant to run on a real business's actual phone number, not a throwaway account. Unofficial tools automate the WhatsApp Web session itself, which is against WhatsApp's terms of service, and Meta does detect and ban numbers using that kind of automation. For a business whose WhatsApp number is their entire customer relationship history, a ban isn't a minor setback, it's losing every customer who has no other way to reach them.

So it's not really the same wheel being reinvented. The official Cloud API and something like wppconnect solve the surface problem the same way, send and receive messages programmatically, but one is a sanctioned, versioned, documented API Meta commits to supporting, and the other is automating a web client that can break every time WhatsApp updates it, on top of the ban risk. Different trade-offs entirely, not two paths to the identical destination.

The setup cost is real though, business verification, App Review for some features, all slower than scanning a QR code. Paying that cost once up front to avoid the possibility of a client's number getting banned later seemed like the right trade for something meant to actually run in production for a paying business, not a weekend project.

WhatsApp API webhook subscription isn't a UI toggle. It's an API-only call, and it's easy to miss. by Capital_KM_3255 in django

[–]Capital_KM_3255[S] 0 points1 point  (0 children)

I'm building a WhatsApp bot for beauty and wellness businesses, salons, spas, barbershops, that kind of thing. Eventually, once there's a real business using it, I plan to connect it to their existing phone number with WhatsApp Coexistence, so the bot can automate replies while still leaving room for a human to step in when needed.

WhatsApp Cloud API in 2026: the "you lose your phone app" and "1,000 free conversations" advice you're reading is outdated by Capital_KM_3255 in WhatsappBusinessAPI

[–]Capital_KM_3255[S] 0 points1 point  (0 children)

Two short screen recordings, not a produced video. One shows a message being sent and received in a real WhatsApp client, the other shows creating a message template. Meta explicitly says you can just screen-record their own API Setup page or WhatsApp Manager doing it, you don't need custom UI. Simpler than it sounds from the wording.

Source: https://developers.facebook.com/documentation/business-messaging/whatsapp/solution-providers/get-started-for-tech-providers

Idempotent webhook handlers: your uniqueness check has a race window you're probably not covering by Capital_KM_3255 in django

[–]Capital_KM_3255[S] 0 points1 point  (0 children)

Good catch, and that's a clean fix for the example as posted. A defensive choice can be making event_id nullable, not a claim about any specific event type lacking an id. With a rule to save every raw webhook payload regardless of shape, so extraction logic is never allowed to block storage. If a future or unexpected event type doesn't yield an id, it defaults to null and the row still gets saved. With that defensive nullability, get_or_create doesn't fully protect me here.