A Customer Support Platform's Embedding Layer

This content is not available in your language yet.

The problem

A customer-support platform already had its own AI feature roadmap — semantic search over help articles, similarity-matching support tickets to past resolutions — and needed a production-grade text-embedding pipeline. Building and hosting an embedding model themselves was more infrastructure than the feature justified; they wanted the embedding vectors, not another platform to operate.

The integration

This is the narrowest possible Wetel integration: a single query, no agent, no session, no workflow. embed(texts: [String!]!) takes a batch of strings and returns 768-dimension vectors, authenticated with a plain API key. The support platform’s backend calls this directly wherever it needs a text embedding, and does its own vector storage and similarity search on its own infrastructure.

See Embeddings for the full query shape and batch-size limits.

Why this shape mattered

Most Wetel integrations assume you want an agent — a persona, a workflow, a conversation. This integration wanted none of that; it wanted one well-tested piece of infrastructure (an embedding model behind a stable API) without adopting the rest of the platform. That the same GraphQL endpoint serves both a full conversational agent and a single stateless utility query is what made this a five-minute integration decision rather than a build-vs-buy debate about a whole platform.

Result

A production dependency added with a single API call, on Wetel’s standard API-key authentication, with no changes needed to the platform’s own architecture, data model, or existing AI roadmap.