Connect SageMaker AI Using Salesforce External Services

Learning Objectives

After completing this unit, you’ll be able to:

• Identify when to use External Services integration.
  
• Describe the API Gateway and SageMaker endpoint integration pattern.
  
• Explain the role of OpenAPI specifications in External Services.
  
• Compare Data 360 and External Services integration approaches.
  
• Evaluate which approach fits your organization's needs.
  

The Alternative Path

You just learned about Data 360 integration, our recommended approach to connect to Amazon SageMaker AI. However, if you don't have Data 360 or you need specific API behaviors that Model Builder doesn't support, there is an alternate approach: External Services. It lets you connect SageMaker endpoints to Salesforce without Data 360.

In this unit, you learn how External Services integration works, walk through the setup process, and compare both approaches.

When to Use This Approach

External Services works best when:

• You don't have Data 360 and don't plan to adopt it.
  
• You need specific API behaviors not supported by Model Builder.
  
• You have API development expertise and capacity.
  
• You need complete control over the integration architecture.
  
• You're integrating with other services alongside SageMaker.
  

This approach requires more technical expertise.

What You Need for the Integration

• Salesforce Platform access
  
• AWS account with SageMaker AI and API Gateway permissions
  
• API development skills
  

How External Services Integration Works

External Services lets you connect external REST APIs to Salesforce using OpenAPI specifications. It provides a low-code way to call external systems from flows or Apex without writing custom integration code.

For SageMaker integration, here’s how External Services works. Your trained model runs on a SageMaker endpoint. API Gateway sits in front of it. You create an OpenAPI spec describing the API. Salesforce imports this spec and creates an invocable action. You can use this action in Flow Builder, Apex, and as an Agentforce Action to enable autonomous AI agents to invoke your SageMaker models as part of multi-step workflows.

This approach gives you flexibility because you control the API design, authentication, and request and response formats.

Let's walk through the high-level integration process.

Step 1: Deploy Your Model

Deploy your trained model to a SageMaker endpoint. Choose the right instance type based on your latency requirements and expected traffic. Start with smaller instances and scale up as needed based on actual performance.

Step 2: Create an API Gateway REST API

Create a REST API in API Gateway and configure it to proxy requests to your SageMaker endpoint. Set up a resource and method that points to your endpoint URL. Then configure request mapping using mapping templates to transform data from Salesforce format to what your model expects. Similarly, configure response mapping to transform predictions from your model's format back to what Salesforce expects.

Step 3: Configure Authentication

First, control who can call your API. On your API method, set the authorization type to AWS_IAM. Then grant the Salesforce principal execute-api:Invoke permission on that method. If you skip this, the method stays open to anyone who finds the URL.

Second, give API Gateway permission to call SageMaker on the caller's behalf. Create an IAM role that trusts apigateway.amazonaws.com, grant it sagemaker:InvokeEndpoint on your endpoint, and set that role as the integration credentials on the method.

The first half decides who gets in. The second half lets API Gateway do its work once they're in.

For more information, see the following:

• Control access for invoking an API
  
• Control access to a REST API with IAM permissions
  
• How do I activate IAM authentication for API Gateway REST APIs?
  

Step 4: Configure Throttling

Set throttling limits on your API by defining requests per second and burst limits to protect your endpoint from overload. Start with conservative limits, monitor actual usage patterns, and adjust as needed. You can always increase limits later based on real traffic data.

Step 5: Create the OpenAPI Specification

Document your API using OpenAPI specification format. This describes the endpoint URL, HTTP methods (GET, POST, and so on), request parameters and body structure, response structure, and authentication method. The OpenAPI spec is what Salesforce imports, so it needs to be accurate. Test it thoroughly before importing.

Step 6: Import as External Service

In Salesforce, create a new External Service and upload your OpenAPI specification. Salesforce validates the spec and, if valid, generates an invocable action that appears in Flow Builder and can be called from Apex.

Step 7: Configure Named Credentials

In Salesforce, the endpoint URL lives on the named credential, and the authentication details live on the linked external credential. Create an external credential using the AWS Signature Version 4 protocol and supply the AWS access key ID, AWS secret access key, AWS Region, and the AWS service name, which is execute-api for API Gateway. Signature Version 4 builds its signing key from the service and Region, so both must match the API you're calling or your requests fail to sign.

Credentials stay out of your code and in the org's encrypted store. Access isn't automatic: grant it with a permission set to whoever makes the callout, including any integration user.

Because those keys are long-lived, limit what they can do. Salesforce calls API Gateway, not SageMaker, so scope the IAM principal behind the keys to execute-api:Invoke on the one API method you're calling. Reaching SageMaker is the job of the API Gateway integration role you created in Step 3. Rotate the keys on a schedule.

For production, you can pair this with Salesforce Private Connect, which uses AWS PrivateLink to route traffic from the Salesforce-managed VPC to a private API Gateway. Traffic travels over the AWS network instead of the public internet, so your API isn't publicly reachable.

For more information, see the following:

• Control access for invoking an API
  
• IAM policy examples for API execution permissions
  
• AWS Signature Version 4 for API requests
  
• Security best practices in IAM
  

Step 8: Test the Integration

Before going live, test everything thoroughly. Send test requests from Flow and verify that responses are correct and error handling works as expected. Test edge cases such as missing data and invalid inputs to ensure your integration handles errors gracefully.

Why Use API Gateway?

SageMaker endpoints provide REST API URLs, so why add API Gateway? API Gateway adds enterprise features that SageMaker endpoints might not have built-in.

• Authentication: API Gateway provides enterprise-grade authentication options including IAM, API keys, or custom authorizers. This adds an additional security layer for controlling access to your endpoint.
  
• Throttling: API Gateway lets you set rate limits to protect your endpoint from overload. If requests exceed the limit, API Gateway rejects them, keeping your endpoint healthy.
  
• Request/Response transformation: If Salesforce sends data in one format and SageMaker expects data in another format, API Gateway can transform requests and responses, mapping between formats automatically.
  
• Monitoring and logging: API Gateway provides detailed logs where you can view every request, track errors, and analyze usage patterns. This helps with troubleshooting and optimization.
  
• Cost control: Throttling and monitoring help control costs by preventing runaway usage, identifying expensive patterns, and providing data for optimization decisions.
  

Compare the Approaches

Compare Data 360 integration and External Services integration side by side.

Best Practices

Regardless of which approach you choose, consider these best practices.

• Start simple: Begin with one use case, get it working, learn from it, and then expand to other use cases.
  
• Test thoroughly: Test with real data, edge cases, and error scenarios—don't skip testing.
  
• Monitor from day one: Set up monitoring before going live to gain visibility into how the integration performs.
  
• Document everything: Document your setup, API specifications, and error handling for future reference.
  
• Plan for failures: Endpoints and networks fail, so implement retry logic, fallbacks, and graceful error handling.
  
• Secure by default: Use encryption, least-privilege IAM roles, and secure credential storage.
  
• Optimize costs: Choose the right instance types, monitor usage, and optimize based on data.
  

Wrap Up

In this unit, you learned about External Services integration and compared both integration approaches. In the next unit, learn about production operations and explore monitoring, cost optimization, error handling, and scaling.

Resources

• AWS Developer Guide: Monitoring AWS resources in Amazon SageMaker AI
• Salesforce Help: External Services
• Salesforce Architecture Center: Data Integration with Salesforce