Einstein Language
Einstein Language was the Salesforce-hosted natural language processing API that exposed three pretrained models to developers: Einstein Intent (classify a text snippet into a custom intent set), Einstein Sentiment (label a text snippet positive, negative, or neutral), and Einstein Named Entity Recognition (extract people, places, organizations, and other entities from text).
Definition
Einstein Language was the Salesforce-hosted natural language processing API that exposed three pretrained models to developers: Einstein Intent (classify a text snippet into a custom intent set), Einstein Sentiment (label a text snippet positive, negative, or neutral), and Einstein Named Entity Recognition (extract people, places, organizations, and other entities from text). It was part of the Einstein Platform Services family, accessed via REST API with a connected app and a JWT-signed token, and aimed at custom apps that needed NLP without owning the ML pipeline.
Einstein Language was retired in late 2024 and replaced by newer Einstein NLU capabilities embedded in Einstein Bots, Service Cloud Einstein features, and the Einstein Trust Layer's text-processing pipeline. For new projects, the right path is the embedded NLU inside the consuming feature (Einstein Bots for intent, Einstein Case Classification for case routing, Einstein Sentiment in Service Cloud for case and chat scoring) or, for custom requirements outside those features, a foundation model via Prompt Builder or Bring Your Own Model in Einstein Studio. Documentation references and Trailhead modules still refer to Einstein Language; the underlying API is not currently accepting new connected apps.
What Einstein Language was, why it retired, and what replaces it
The three pretrained APIs
Einstein Language exposed three endpoints. Intent took a text input and a dataset of trained examples and returned the predicted custom intent. Sentiment took a text input and returned positive, negative, or neutral with confidence scores. NER took a text input and returned a list of entities with their types (PERSON, LOCATION, ORGANIZATION, DATE, MONEY, and others). The endpoints were stateless and the responses were JSON. Custom apps consumed them by HTTP, fed the result back into Salesforce records, and acted on the labels.
Authentication via Einstein Platform Services
Einstein Language sat under the Einstein Platform Services umbrella, sharing infrastructure with Einstein Vision. Authentication was via a connected app, a private key downloaded from the platform settings, and a JWT signed against the private key. The JWT was exchanged for a short-lived OAuth token used on each API call. The pattern was identical to other Einstein Platform Services and let Apex callouts or any external server hit the endpoints. The auth setup was non-trivial for click-not-code admins, which is one reason adoption stayed lower than Salesforce expected.
Custom Intent training and dataset management
For Einstein Intent, the developer uploaded a labeled dataset (CSV with text and label columns), trained a model on the dataset, and then called the model for predictions. Training was asynchronous and produced a model ID. Predictions referenced the model ID and returned the top intent with a confidence score. Re-training required a new dataset upload and a new training call. Salesforce hosted the model. Updating intents over time meant re-uploading the full dataset, not incremental additions. The pattern worked but was clunkier than modern fine-tuning workflows.
Why it retired
Several forces converged. Einstein Bots absorbed the intent-classification use case for conversational apps and embedded the NLU directly in the bot builder. Service Cloud Einstein absorbed the sentiment use case for case and chat scoring with a managed feature. Foundation models made standalone NER and intent APIs feel underpowered for the new generation of tasks teams wanted to run. Maintaining a separate API surface with its own auth and its own dataset workflow was no longer worth the small audience using it. Salesforce signaled retirement in 2024.
The modern replacement paths
For intent classification on customer conversations, Einstein Bots is the replacement. For case classification in Service Cloud, Einstein Case Classification handles it natively. For sentiment on service interactions, Einstein Sentiment in Service Cloud is the embedded option. For custom text classification outside those features, Einstein Prediction Builder works on text fields. For more complex NLP (entity extraction, summarization, multi-class text understanding), a foundation model via Prompt Builder produces better results than the old Einstein Language API at lower setup cost.
Migrating an existing Einstein Language integration
Apps still calling Einstein Language need a migration plan. Inventory every consumer. For intent classification, plan whether the use case fits into Einstein Bots (live conversational) or Einstein Prediction Builder (record-level). For sentiment, evaluate Einstein Sentiment in Service Cloud or a Prompt Builder template with a structured output schema. For NER, the cleanest replacement is usually a Prompt Builder template that returns a structured JSON list. Each replacement path has different governance characteristics; map them against the original integration's requirements.
Lessons from the retirement
Einstein Language was a useful capability that sat awkwardly in the platform. It required developer skill to consume, lived outside the standard CRM data model, and competed with embedded features that were easier to adopt. For new AI capabilities, the lesson is to embed in the consuming feature rather than expose a generic API. Salesforce has followed this pattern with Agentforce, Einstein Trust Layer, and Prompt Builder, where the capability is shaped by the surface that uses it.
How to plan a migration off Einstein Language
Einstein Language is retired. Migrations need to map each existing call to the right modern replacement; the steps below cover the planning, not the deprecated build.
- Inventory every Einstein Language call
Search the codebase for the Einstein Platform Services base URL or the intent, sentiment, and NER endpoints. List every consumer, the dataset it depends on, and the downstream consumer of the prediction.
- Classify each call by use case
Group calls into conversational intent, record classification, sentiment scoring, and entity extraction. The replacement path depends on the use case category, not the original API endpoint.
- Pick the modern replacement
Conversational intent goes to Einstein Bots. Record classification goes to Einstein Case Classification or Prediction Builder. Sentiment goes to Einstein Sentiment in Service Cloud. Entity extraction usually goes to a Prompt Builder template returning structured output.
- Re-train or re-template on the new path
Most replacement features need their own training data or prompt design. The old Einstein Language dataset can seed the new path but rarely transfers directly because the surface differs.
- Cut over with a parallel-run period
Run the new path alongside the old call for one to two weeks, comparing outputs. Cut over when the new path matches or beats the old on the team's evaluation set.
The replacement for live conversational intent classification. NLU is embedded in the bot builder.
The replacement for case-level text classification. Trains on historical cases and fills in Type and Reason fields.
The replacement for case and chat sentiment scoring. Embedded in Service Cloud.
The replacement for entity extraction and custom text understanding. Structured output schemas make the returned data machine-readable.
The fallback when no embedded feature fits. Custom model trained externally and registered in Einstein Studio.
- Einstein Language is not currently accepting new connected apps. Treat any new integration request as a migration to a modern path.
- Existing apps that have not migrated are on borrowed time. Even if calls still succeed, the API has a retirement timeline and support is winding down.
- The old auth pattern (JWT signed against a downloaded private key) does not transfer to the new paths, which use standard Salesforce authentication and metadata.
- Trailhead modules and old documentation still reference Einstein Language. Confirm with current release notes before recommending it for a new project.
- Replacement paths produce different output formats. Downstream consumers need to be updated, not just the API call.
Trust & references
Straight from the source - Salesforce's reference material on Einstein Language.
- Einstein platform overviewSalesforce Help
- Einstein Bots overviewSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Einstein Language provide?
Q2. Can Einstein Language be trained on custom intents?
Q3. What's a typical use case?
Discussion
Loading discussion…