#API13 debatiendo

Hi @Sai Kumar Good question! Salesforce REST API integration is an important skill for developers. I suggest starting with the basics and practicing in a Developer Org.

1. Essential Steps to Learn

1. REST API Basics: Understand GET, POST, PUT, PATCH, DELETE, JSON, and HTTP status codes.
2. Authentication: Learn OAuth 2.0, access tokens, and secure API access.
3. Named Credentials: Configure External Credentials and Named Credentials to manage endpoints and authentication securely.
4. Apex Callouts: Use HttpRequest, Http, and HttpResponse to communicate with external APIs.
5. JSON Handling: Practice JSON.serialize() and JSON.deserialize().
6. Error Handling: Handle API failures, timeouts, and unexpected responses.
7. Testing: Use HttpCalloutMock to write Apex test classes without making real API calls.

2. Practical Project

Build a simple Currency Converter or Weather Application.

• Call a public REST API from Apex.
• Display the API response in an LWC.
• Handle errors and test different responses.

3. Official Salesforce Resources

• Apex Integration Services
• Named Credentials
• Apex REST Callouts
• Apex Callout Testing

Start with a simple GET API, then practice POST requests, OAuth authentication, and error handling.

Key Point: Focus on understanding the complete integration process, not just writing Apex callout code.

Hope this helps!

Venkat Yadav | SFDCINDIA

@Abhimanyu Singh the form export is only the prospect fields. The page path lives on other objects.

In Account Engagement API v5, a form submission is a visitor activity, not a column on the prospect export. Query GET /api/v5/objects/visitor-activities and filter by that prospect. A completed form is type 4 with typeName Form. Looking at the form without submitting is type 2. You need the Prospect, Visitors, View ability for that call.

The pages themselves are visitor page views. GET /api/v5/objects/visitor-page-views with the visitId, and read url, title, and createdAt. The visit record has firstVisitorPageViewAt and lastVisitorPageViewAt, so the earliest page view on that visit is your first page and the latest one is the exit page. GET /api/v5/objects/visits tied to the same prospect gives you the visitId that matches the form activity.

If you need this in bulk, the Export API can pull Visitor Activity and include relationship fields like prospect.email in one file. Visitor page views are their own export, so you still join them on visitId. I haven't seen a form-submission file that already has the page history on it. You'll only get the path as far back as Account Engagement still stores those visits.

Hi Anirudh,

For ~20K Data Extensions, manually checking each DE isn't practical. One option is to automate the inventory using the SFMC REST/SOAP APIs. 

However, SFMC doesn't provide a simple standard field on the Data Extension definition that represents the latest record insertion date. You would need to determine that from the data itself (for example, if the DEs contain a CreatedDate/EntryDate field) or from the process that populates them. 

If your DEs have a consistent date field, you could build an automation/script that:

1. Retrieves the list of Data Extensions through the API.
2. For each DE, determines the latest relevant date from the data.
3. Compares that date with your one-year cutoff.
4. Produces a report of DEs that haven't received data in the last year.
5. After reviewing the report, delete the obsolete DEs through the API.

I would recommend generating the report first rather than automatically deleting 20K DEs, so you can validate the results before performing the cleanup. 

If the DEs don't have a consistent date/inserted timestamp field, please share how the records are loaded into them (Automation Studio, Journey Builder, API, imports, etc.). That will determine the best way to identify the last activity.

@Tara Morton

  Great review of details.  

I am currently testing the Tableau MCP connector with Claude and wanted to document the issue we are experiencing and confirm the best supported path forward. 

We have successfully added the official Tableau MCP connector/extension in Claude, and it works as expected in standard Claude Chat. However, when attempting to use Tableau through Claude Cowork, the Tableau tools are not available.  

In Claude Cowork, we ran ToolSearch for the following terms:

• Tableau
• tableau-mcp
• Tableau MCP
• workbooks
• datasources
• published data sources

The result was that no Tableau tools were found. Claude Cowork also explicitly stated:

“I do not have Tableau MCP tools in my allowed tools list for this Cowork session.”

Based on feedback from Anthropic support, the likely reason is that the Tableau .mcpb Desktop Extension is designed for local Claude Desktop environments and cannot run in web-based Claude Cowork.  

 Please let us know the best supported implementation path, whether this is currently available, and any documentation or examples you can share.  

Thank you in advanced.

Hi @Kevin Miller - One small thing to keep in mind when sending Contact Form 7 data directly to Salesforce:

• Use the Salesforce REST endpoint like 
   /services/data/vXX.X/sobjects/Lead/

• Authenticate with OAuth (Connected App).
• Map the CF7 fields to Lead fields such as FirstName, LastName, Email, Phone.
• If needed, you can also send extra fields like Lead Source = Website so you can track where submissions came from.

For more advanced setups later, you can also trigger a Salesforce Flow on Lead creation to handle things like assignment rules, campaign association, or notifications.