Einstein Vision
Einstein Vision was the Salesforce-hosted computer vision API in the Einstein Platform Services family.
Definition
Einstein Vision was the Salesforce-hosted computer vision API in the Einstein Platform Services family. It offered four pretrained model types accessible via REST: Image Classification (label an image from a custom class set), Object Detection (identify and bounding-box objects in an image), Visual Search (find visually similar images from an indexed set), and the OCR endpoint for extracting text from images. Custom apps consumed the API by HTTP, sending image bytes or URLs and receiving JSON predictions, then writing the result back into Salesforce records as needed.
Einstein Vision was retired alongside Einstein Language in late 2024 as the Einstein Platform Services family wound down. Salesforce's visual AI capabilities now live inside specific surfaces (Field Service for image-based diagnosis, Commerce Cloud Einstein for product recommendations from images, Files for visual search inside the org) rather than as a generic API. For custom computer vision needs outside those surfaces, the modern path is Bring Your Own Model in Einstein Studio with a vision model trained externally and registered for use through prompt templates or flows.
What Einstein Vision did, why it retired, and what replaces it
The four pretrained vision tasks
Einstein Vision exposed four task families. Image Classification labeled an image from a custom dataset (good/bad product photo, damage type on a vehicle, plant species). Object Detection drew bounding boxes around objects in the image and returned their labels and confidence scores. Visual Search compared an input image against a previously indexed set and returned the closest matches by visual similarity. OCR extracted text from images, including printed and limited handwriting cases. The four were independent endpoints sharing the same auth and dataset infrastructure.
The dataset and model lifecycle
To train a custom classifier or detector, the developer uploaded a labeled dataset (a ZIP of folders for classification, a structured archive for detection), kicked off training, and waited for completion. Training was asynchronous and produced a model ID. Inference calls referenced the model ID and an image (bytes or URL). The dataset and model both lived on Salesforce-hosted infrastructure. Re-training required uploading a refreshed dataset and a new training call. Incremental updates were not supported; each retraining was full.
Authentication and developer experience
Authentication was through a connected app and a JWT signed against a downloaded private key, identical to Einstein Language. The developer issued a JWT, exchanged it for a short-lived OAuth token, and made REST calls with the token. The pattern was clear once mastered but heavy for a click-not-code admin. Salesforce never built a UI to manage Einstein Vision datasets and models at the level of polish found in features like Einstein Prediction Builder. The friction limited adoption to teams with developer capacity.
Common use cases people built on it
Field service teams used Image Classification to flag damage types from technician photos. Insurance customers used it for claims triage from accident photos. Retail teams used Visual Search to match customer-submitted images to product catalog. Manufacturing teams used Object Detection to count parts in shelf photos. Each of these has a modern home now: Field Service has image intake built in, Commerce Cloud Einstein covers visual product matching, and custom vision tasks flow through Einstein Studio. The retirement preserved the use cases by relocating them.
Why the API retired
The same forces that retired Einstein Language. Embedded features absorbed the most common use cases. Foundation models that handle multimodal input (vision-and-language combined) became the new standard for custom tasks. Maintaining a separate API surface with its own auth, dataset, and model registry workflow was no longer worth the small audience using it. Salesforce announced the retirement timeline in 2024 and stopped accepting new connected apps for the API.
The Bring Your Own Model path for custom vision
For custom computer vision needs that fall outside the embedded features, the modern path is Einstein Studio with a Bring Your Own Model registration. Train a vision model in Databricks, Vertex AI, or SageMaker, register the endpoint in Einstein Studio, and expose it to flows and prompt templates. The team owns the model lifecycle and refresh, but gains the Einstein Trust Layer integration when calls flow through prompt templates rather than direct Apex callouts.
Migration planning for existing Vision consumers
Apps still calling Einstein Vision need a migration plan. Inventory each consumer. Classify the use case as embedded-feature-compatible or custom. Embedded paths are faster and lower-maintenance but constrained to the feature's data model and UI. Custom BYOM paths are flexible but require ongoing model ownership. Run the new path in parallel for one to two weeks, evaluate accuracy against the production set, then cut over.
How to migrate an existing Einstein Vision integration
Einstein Vision is retired. The steps below cover migrating an existing consumer to a modern path; do not build new integrations against the retired API.
- Inventory every Vision API call
Search the codebase for the Einstein Platform Services base URL or the predict, train, and dataset endpoints. List each consumer with the dataset it depends on and the downstream consumer of the prediction.
- Map each call to a use case category
Sort calls into damage assessment, document OCR, visual product matching, asset counting. The replacement depends on the category, not on which Vision endpoint was called.
- Pick the modern replacement
Field service image classification often moves to embedded Field Service intake. Document OCR often moves to Salesforce OCR services in Cloud or Files. Visual product matching often moves to Commerce Cloud Einstein. Truly custom needs go to BYOM in Einstein Studio.
- Train or register the replacement model
Embedded features need their own dataset configuration. BYOM needs an external training pipeline and registration in Einstein Studio with an exposed endpoint.
- Cut over with parallel-run validation
Run the new path alongside the old call for one to two weeks. Compare predictions on a hand-graded sample. Cut over when the new path meets or beats the old accuracy.
The replacement for technician photo classification in Field Service. Damage assessment lives in the work order workflow.
The replacement for visual product matching and visual search use cases in commerce contexts.
For visual search inside a Salesforce org, the Files feature offers indexed similarity search without separate API plumbing.
The fallback for custom vision needs. Train externally, register in Einstein Studio, call from flows or prompts.
Some Prompt Builder paths accept image inputs alongside text, letting a foundation model classify or describe images directly.
- Einstein Vision is retired. New connected apps cannot register. Existing apps should plan a migration even if calls currently succeed.
- BYOM requires owning the model lifecycle: training, retraining, monitoring, and refresh. The platform does not manage these for custom models.
- Embedded replacements carry their own data model. The output may need transformation to match what the original Einstein Vision integration consumed.
- Direct Apex callouts to external vision models bypass the Einstein Trust Layer. Wrap calls in prompt templates if Trust Layer governance is required.
- Older Trailhead modules and developer docs still reference Einstein Vision. Confirm against current release notes before quoting them as guidance.
Trust & references
Straight from the source - Salesforce's reference material on Einstein Vision.
- Einstein StudioSalesforce Help
- Einstein platform 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 Vision provide?
Q2. What's a typical use case?
Q3. Can Einstein Vision be trained on custom models?
Discussion
Loading discussion…