Bringing an External CRM's Chats into Firestore for AI Search: Vector Search, Webhooks, and a Stubborn Bundling Error

A developer integrated an external CRM's chat history into Firestore to power an AI assistant's semantic search, overcoming a recurring bundling error and a cursor bug. The solution reused existing functions, added server-side contact search with debouncing, and leveraged Firestore's native vector search for querying thousands of conversations.

A client wanted their management panel's AI assistant to answer questions like "what did this contact write me" or "who replied about a certain topic", pulling from thousands of conversations held on an external CRM. Between the idea and the first correct answer there was a bundling error that came back three times, a cursor that never advanced, and a phone number that pointed to the wrong contact. The client's management panel already had a solid integration with the external CRM used to handle WhatsApp, SMS, and email conversations with contacts: reading sales pipelines, opening chat with bubbles and attachments, sending replies. All reusable infrastructure, already in production for a while. One specific piece was missing: no function queried the CRM's full contact directory — only opportunities inside a specific pipeline — and, more importantly, there was no way at all for the panel's AI assistant to read past conversations. First rule, before writing a single new line of code: reuse what already worked. The function that read multiple pipeline stages in parallel, the modal that opened chat with full history, the function that sent messages — all proven and already in use. The one genuinely missing piece was a function able to search the entire contact directory, with text search and pagination, which the existing functions built for single pipelines didn't do. With tens of thousands of contacts in the directory, loading them all client-side to filter isn't an option. The correct approach is server-side search: on every keystroke debounced by 400ms to avoid hammering the API , the backend function forwards the query to the CRM's own search engine, which runs it against the entire archive — name, phone, email — not just the results already shown on screen. What the user sees, 30 contacts at a time with a "load more" button, is only the current page, not the search scope. A real limitation worth knowing: a third-party CRM's search is almost always a "contains" match, not fuzzy — it doesn't tolerate typos or a swapped first/last name. Worth keeping in mind both in the UI and, later in this story, in a piece of AI logic that broke for exactly this reason. Before tackling the hard part, two minor fixes noticeably improved the contact directory's usability. The first was a misalignment between column headers and table rows: caused by using two different layout systems, a flex container for the header and a real table for the rows, which could never match in width. The fix was putting the header inside a real <thead in the same table, with a <colgroup fixing the same widths for both. The second was a cascading tag filter: a new function lists every tag that exists in the account not just the ones seen among the contacts already loaded on screen , populates a dropdown, and selecting one reruns the same text search passing the tag name — zero new endpoints for the actual filtering, since the CRM's search engine already covered tags too. At that point came the request that changed the nature of the work: the client wanted every contact and every conversation to also persist in their own database, kept up to date over time, queryable by the panel's AI assistant — no longer just fetched on the fly from the CRM when needed. With nearly 48,000 contacts and a chat history growing daily, this stopped being one more feature and became an architecture decision. The first decision, and the one worth getting right: Realtime Database retransmits the entire node on every write, to every connected client. With tens of thousands of contacts and conversations that keep growing, a node like contacts/{id}/messages would have become a bandwidth problem from the very first wave of writes. Firestore, by contrast, supports indexed queries, subcollections that grow without rewriting the parent document, and — the decisive reason here — native vector search, exactly what's needed for semantic search across all conversations at once, without adding a separate vector database to pay for and manage. The data model is one document per contact profile, tags, last sync with a messages subcollection for history — not an array inside the document itself. A contact with hundreds of messages would soon hit the one-megabyte-per-document limit, and more importantly every new message writes a single new document instead of rewriting the entire history each time. Writing and querying vector fields on Firestore reliably means using the official firebase-admin SDK, not the raw REST API. That runs against a project convention — zero npm dependencies in the existing Netlify Functions — and the exception made itself felt on the very first deploy: Cannot find package 'firebase-admin' imported from /var/task/... , despite the package being correctly declared in a dedicated package.json . The cause is a function-bundling problem, not a code problem: the bundler simply wasn't packaging the dependency into the final zip. First attempt, explicitly setting the modern bundler via node bundler = "esbuild" in the config — same error. Second attempt, explicitly marking the package as "external" so it wouldn't be bundled external node modules , the documented standard fix for exactly this case — again the identical error, a sign the problem was no longer bundling but the install step itself during the build. The definitive fix, when the "clean" routes aren't enough.No more half-measures: download the dependencies ahead of time and commit them already installed into the repository so-called "vendoring" of node modules , so the platform finds them already there instead of having to install them during the build. The interesting practical detail: the client works entirely from a browser, with no local terminal. The solution was a browser-accessible cloud dev environment a "codespace" with a real built-in terminal: npm install inside the functions folder, then commit and push the generated files straight from the interface — zero commands to install on the person's own computer. With node modules physically present in the repository, the next deploy went through on the first try. With bundling solved, actually importing nearly 48,000 contacts can't be a single call: it has to run in batches, repeated by a function scheduled every few minutes, with a progress cursor saved on Firestore to resume exactly where it left off. The first real run revealed a subtler problem: the cursor stayed null forever. The configured batch 25 contacts simply couldn't finish within the function's time budget, so every execution restarted from the same initial contacts — not only failing to advance, but also re-paying for embedding every message that had already been embedded before, a silent and entirely avoidable cost. The fix had two parts: shrink the batch size to something that genuinely completes within the available time budget, and — more importantly — check which messages already had an embedding saved from a previous run, skipping them instead of regenerating them. With that fix, the cursor finally started advancing, and a rough estimate based on the observed pace put the full historical import at about a day and a half. For new messages, the CRM's automation offered a "customer replied"-style trigger — but with a non-obvious limitation: the variables available in the webhook body exposed the contact's identity, not the message text or its real timestamp. And, more importantly, no equivalent trigger existed for "the operator replied": automation engines of this kind react to customer actions, not to internal team actions. The sturdier fix wasn't chasing a trigger that probably doesn't exist, but changing how the available one gets used: the webhook no longer carries the message text, only the contact's identity, used as a signal meaning "this contact was just active, resync it now." The function it calls re-reads the entire fresh conversation from the same API the backfill already uses — which includes both inbound and outbound messages in the same fetch. One available trigger, full coverage on both directions. A second, lighter webhook, attached to contact-created/updated triggers, covers tag or profile changes that happen without a new message. An unplanned side effect: imported messages started including system events like "opportunity deleted", generated by the CRM whenever an opportunity changes stage — not text written by either side of the conversation. The fix, minimal but needed in three separate places the real-time webhook, the shared sync function, and the backfill job already live in production , was to explicitly filter these events by type before saving them or generating an embedding for them. A practical reminder about this kind of change: an import job that's already live and running should be fixed with surgical patches, not rewritten for code cleanliness midway through — the risk of introducing a new bug while it's processing tens of thousands of records far outweighs the cosmetic benefit. The first real test of AI search immediately exposed the limit of semantic search: searching for a phone number with the vector engine doesn't work, because the number doesn't appear in the meaning of the message text. What was needed was a direct identity lookup, not a content search — two different tools for two different questions. The first attempt at a phone lookup produced a sneakier bug: a ten-digit local number that happened, by pure coincidence, to start with the same digits as the Italian country code was mistaken for an already-complete international number — and the search stopped at the first match found, returning the wrong contact with no warning at all. The correct fix wasn't "guess better" but checking every plausible variant in parallel with and without the country code and, if different contacts turn up, explicitly flagging the ambiguity instead of picking one at random. The same principle was then extended to a direct lookup by exact name and by tag, both with an automatic, silent fallback to semantic search whenever the direct match finds nothing. An easy detail to underestimate: timestamps were correctly stored in UTC, as they should be, but were passed to the language model as-is, leaving it to mentally convert them to local time in its final answer. The result was silently off by two hours, with no error to catch — a message from 1:22 PM local time was presented as 11:22 AM. The reliable fix wasn't a more insistent prompt instruction, but removing that calculation from the model entirely: converting the timestamp server-side to the correct time zone automatically handling daylight saving as well before injecting it into the context, and explicitly stating that the time received is already local, so the model doesn't attempt the conversion again on its own. One last problem, more mundane but frequent: some answers with long lists of messages were getting cut off halfway, with the last item — often the most recent and the most relevant one — missing. The cause was simply a response token budget too low for the language model. The fix has three layers, not just one: raise the maximum response token budget, order lists from most recent message to oldest so any future truncation drops the least relevant data, not the freshest , and explicitly instruct the model to stay compact in its formatting, so it doesn't waste response headroom on unnecessary decoration. The broader lesson is that reusing existing infrastructure saves real time, but changing scale from a few on-the-fly reads to tens of thousands of persistent, queryable records is always an architecture decision, not just a code one — worth stopping to decide explicitly before writing the first line. Making an exception to an established convention like "zero npm dependencies" needs a plan B ready in advance: if standard bundling doesn't work on the first try, manually vendoring dependencies is a slow but reliable path, and it's better to know that before deploy day, not during it. Identity search and semantic search are two different tools, not one tool with two modes: using the wrong one produces a result that looks plausible but is silently incorrect, the hardest kind of bug to spot. And finally, the most annoying bugs in this work were never the "big" decisions — Firestore or RTDB, vector or text search — but the small, silent details: a time budget too tight, a time zone left unconverted, a token limit set too low. None of these throws a visible error: they just produce a wrong answer that looks right. If you're interested in the broader reasoning behind database choices in this same management panel, I also wrote about migrating RTDB rules after an authentication issue. And if you want to see how the AI assistant that learned to read these chats is structured in the first place, the starting article is the one on the Gemini API chatbot inside the management panel. Why use Firestore instead of Realtime Database to store a CRM's conversations? Because Realtime Database retransmits the entire node on every write, to every connected client: with tens of thousands of contacts and growing conversations that becomes a bandwidth problem. Firestore instead supports indexed queries, subcollections that grow without rewriting the parent document, and the native vector search needed for semantic search. What is vector search and what is it useful for in a case like this? It's a search by meaning rather than by exact words: each message is turned into a numeric vector embedding by an AI model, and a query of the same kind finds the semantically closest messages. It's useful for questions like "who asked for a refund this month", where the exact wording of the question never appears in the original messages. Why can a Netlify Function with a dependency like firebase-admin fail in production even if it works locally? Because the function bundler sometimes fails to correctly package heavy dependencies with native bindings or dynamic require calls, even when explicitly setting the modern bundler or excluding the package from the bundle. In the most stubborn cases the only reliable fix is vendoring node modules — committing it already installed into the repository instead of letting it install during the build. Why can a phone number without its country code lead to the wrong contact? Because a search that stops at the first match found, without checking every plausible variant of the number with and without the country code , can return a different contact than the one being searched for by pure numeric coincidence. The correct fix is checking every variant in parallel and explicitly flagging an ambiguity instead of picking one at random. Is it possible to capture both inbound and outbound CRM messages in real time? It depends on the CRM: many automation engines offer a "customer replied" trigger but no native trigger for "the operator replied". In that case, it's better to use the available trigger only as a "this contact is active, resync it" signal, and re-read the whole conversation from an API that returns both directions in a single pass. Why can timestamps stored in UTC appear wrong in an AI-generated answer? Because if the model is left to mentally convert a UTC timestamp to local time, the calculation can be silently wrong. The reliable fix is converting the time server-side before passing it into the prompt, and explicitly stating to the model that the time is already local, so it doesn't attempt the conversion again on its own.