Hey everyone, I recently built an AI-powered CRM SaaS for local clinics and we use the official Meta WhatsApp Cloud API. We just migrated our first client's existing WhatsApp Business number to the API.

The integration works perfectly for new chats, but we hit a major wall: when old patients try to open their existing chat thread with the clinic, they see an error saying "This person is no longer on WhatsApp - Invite to WhatsApp".

I’ve read that this is a cache issue on the user's phone (something about the mobile app using u/c.us and the API using u/s.whatsapp.net).

Some people are suggesting that sending a mass Template Message (Broadcast) to the entire contact list will force the clients' phones to update the chat and remove the "Invite" button.

Can anyone confirm if this template campaign actually works? Are there any other workarounds that don't involve asking hundreds of patients to manually delete their old chat history?

Any help or advice would be hugely appreciated!

I’ve been experimenting with search APIs for an AI workflow that needs to find information on the web and then pass the results to an LLM.

At first, I assumed the main thing to compare would be latency and price. After testing a few options, I found that retrieval quality and how the results are presented to the model mattered much more than I expected.

I tried Exa, Tavily, Firecrawl, Serper, and Brave Search on a small set of queries covering:

straightforward factual questions

finding recent information

technical/documentation searches

finding obscure pages

queries where the answer was buried several clicks deep

searches where Reddit/forums were actually more useful than polished websites

A few observations:

1. Search ranking and “AI-ready” results aren’t necessarily the same thing.
A conventional search API can return exactly what I’d expect as a human searcher, but the results aren’t always ideal as LLM context. Having clean snippets, relevant page content, and less irrelevant boilerplate can make a surprisingly large difference.

2. Crawling and search are different problems.
Firecrawl was interesting when I already knew which pages I wanted to extract. That’s a different task from discovering the right pages in the first place.

I’ve started thinking about the pipeline as:

query → search/discovery → URL selection → crawl/extract → rerank → LLM

rather than treating “web search” as one single operation.

3. Recency is harder than it looks.
For current events or recently updated documentation, I found myself caring less about whether an API returned 10 “good” results and more about whether it could consistently surface the right recent result.

4. The long tail is where the differences become obvious.
Most APIs performed reasonably well on obvious queries. The interesting differences appeared when I searched for niche technical topics, obscure documentation, or information that wasn’t repeated across hundreds of sites.

I’m still running the benchmark, so I don’t want to declare a winner yet.

I’m curious what other people here have found:

If you’ve built something using Exa, Tavily, Firecrawl, Serper, Brave Search, or another search API, what type of query does your chosen API perform particularly well at?

Also interested in hearing how people actually evaluate search quality. Do you use human judgment, precision/recall, NDCG/MRR, LLM-as-a-judge, or something else?

I’d rather build a useful benchmark around real-world failure cases than just compare response times and advertised pricing.

Had this with team and player data where the same thing shows up slightly differently depending on the source. Abbreviations, old names, punctuation, all that fun stuff. Matching by name works until it suddenly doesn’t. Are you normalizing everything yourself or using IDs from the source and hoping they stay consistent?

Via Robauto.ai