Claude Integration with Salesforce: A Practical Guide

There is no official "Claude for Salesforce" package in the AppExchange, and Salesforce's native AI features (Einstein, Agentforce) run on Salesforce's own models, not Claude. If you want Claude specifically — for drafting case responses, summarizing opportunities, generating Apex/SOQL, or building an agent that reads and writes CRM data — you have to wire it up yourself using Salesforce's standard integration primitives: Apex HTTP callouts, Flow with External Services, or a middleware layer.

That's genuinely the most direct path, and it's not complicated. The rest of this article covers the three realistic ways to do it, with a working code example, and where the tricky parts actually are (auth, rate limits, streaming inside Salesforce's synchronous callout limits).

Why teams want Claude specifically inside Salesforce

Common reasons a team reaches for Claude instead of (or alongside) Einstein:

• Better long-context reasoning for summarizing long case histories, contracts, or email threads attached to a record.
• Tool use / function calling to let Claude decide when to query related records, create tasks, or draft follow-up emails.
• Consistency — teams already use Claude elsewhere (support, docs, engineering) and want the same model behavior in the CRM instead of learning Einstein's separate prompt/config system.
• Custom Apex/Flow generation for admins who want AI help building automations, which Einstein doesn't do well.

Option 1: Apex HTTP callout, direct to the model API

This is the lowest-level approach and works well for anything triggered from a record page, trigger, or scheduled job.

1. Set up a Named Credential pointing to your API endpoint so the auth header and URL are managed by Salesforce, not hardcoded in Apex.
2. Write an Apex class that builds the JSON request and parses the response.
3. Call it from a trigger, Invocable Method (so Flow can use it), or Lightning Web Component.

public class ClaudeCallout {
    @InvocableMethod(label='Ask Claude')
    public static List<String> ask(List<String> prompts) {
        List<String> results = new List<String>();
        for (String prompt : prompts) {
            HttpRequest req = new HttpRequest();
            req.setEndpoint('callout:Claude_API/v1/messages');
            req.setMethod('POST');
            req.setHeader('Content-Type', 'application/json');
            req.setBody(JSON.serialize(new Map<String, Object>{
                'model' => 'claude-3-7-sonnet',
                'max_tokens' => 1024,
                'messages' => new List<Object>{
                    new Map<String, Object>{ 'role' => 'user', 'content' => prompt }
                }
            }));
            Http http = new Http();
            HttpResponse res = http.send(req);
            results.add(res.getBody());
        }
        return results;
    }
}

Wrapped as an Invocable Method, this same class becomes callable from Flow Builder with zero extra code — an admin can drag it into a record-triggered flow and pass in field values as the prompt.

The catch: Salesforce Apex callouts are synchronous by default and capped at a 120-second timeout, with a 10-callout limit per transaction. Fine for single-turn requests; not fine for long streaming responses or multi-step agent loops. For those, use Queueable Apex or Platform Events to move the work asynchronous.

Option 2: Middleware / iPaaS

If you already run MuleSoft, Workato, or Zapier for other Salesforce integrations, adding Claude as another connected step is often faster than writing Apex. The trade-off is cost and latency — you're adding a hop, and most iPaaS platforms charge per task/run, which adds up fast if Claude is called on every case update.

This approach makes sense when:

• Non-developers need to build or edit the automation.
• You need to fan out to multiple systems (Slack, email, ticketing) in the same flow, not just Salesforce.
• You're already paying for the platform and it's a marginal addition.

Option 3: A hosted API layer between Salesforce and Claude

Whether you call Claude directly from Apex or through middleware, you still need to solve auth, rate limiting, and usage tracking across whoever on your team is building Salesforce automations. This is where a gateway like SubToAPI is useful: it turns your existing Claude access into a standard HTTPS API with sub_live_... application keys, so your Salesforce integration authenticates the same way any other internal service does, instead of every admin needing separate direct API credentials.

Practically, this looks like pointing your Named Credential at https://api.subtoapi.app/v1/messages with an Authorization: Bearer $SUBTOAPI_KEY header:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-3-7-sonnet",
    "max_tokens": 512,
    "messages": [
      {"role": "user", "content": "Summarize this case thread: ..."}
    ]
  }'

That's it on the Apex side — nothing else changes from Option 1. What you get on top is per-key usage metadata (useful when finance asks which automation is generating API cost) and team seats, so a Salesforce admin, a backend developer, and an ops lead can each have their own key under one plan instead of sharing credentials in a Named Credential that nobody remembers rotating. Plans start at €9/month (Solo), €19/seat (Team), or €49/seat (Scale) — see /pricing. Setup takes about the same time as reading /docs/quickstart.

Handling tool use for CRM actions

If you want Claude to actually take actions in Salesforce — create a task, update a field, look up a related account — use tool/function calling rather than parsing free text out of the response. Define tools that map to specific Apex-callable actions and let the model choose when to invoke them; the request/response shape is documented at /docs/tools. This keeps the model's write access scoped to exactly the operations you expose, instead of letting it generate arbitrary Apex or SOQL.

Getting started

1. Pick your trigger point: record-triggered Flow, Apex trigger, or scheduled batch.
2. Decide sync vs. async based on expected response time (single completion vs. multi-step tool use).
3. Set up a Named Credential for auth instead of hardcoding tokens in Apex.
4. If you need shared team access and usage visibility across multiple builders, put a gateway like SubToAPI in front — /docs/messages covers the request format, /docs/streaming covers streaming responses for longer-running UI-facing calls.

FAQ

Does Salesforce have a built-in Claude integration? No. Salesforce's native AI (Einstein, Agentforce) uses Salesforce's own models. Claude has to be connected via Apex HTTP callouts, Flow External Services, or a middleware/iPaaS tool.

Can I call Claude from Flow Builder without writing Apex? You still need a small Apex Invocable Method to make the HTTP callout, but once that class exists, admins can reuse it in any Flow without further code.

What's the fastest way to give multiple Salesforce developers access to Claude? Route calls through a single API endpoint with per-user keys instead of sharing one credential. A gateway like SubToAPI provides this out of the box with team seats and usage tracking — see /signup to try it.