#Integration51 discussing

Short answer: For an APEX-defined Integration, the endpoint and authentication are not set inside the Integration Definition record itself — they're set inside your Apex.class that implements the DataSource.Load (or VlocityOpenInterface) interface. Inside that class's load() method, you build an HttpRequest and set the endpoint URL there, and for auth, best practice is to use a Named Credential (endpoint = callout:YourNamedCredential/path), so Salesforce handles the token/credentials instead of hardcoding them in code. 

In the Integration Definition, you only specify: 

• Type = "Apex Class"
• The name of the class implementing the interface
• The request/response JSON structure (so the Integration Procedure knows how to map the data)

Then in the Integration Procedure, you just drop in an "Integration Action" element pointing to that Integration Definition — it calls your Apex class, which handles the endpoint and auth internally. 

If you're using External Service Defined instead, the endpoint/auth is already configured via Named Credential when you set up the External Service itself (Setup > External Services) — no extra Apex needed in that case. 

Hey everyone, I ran into this exact same issue while setting up the Marketing Cloud connection in Trailhead/Sandbox and finally got it resolved. 

If you are getting the error "There was an error communicating with Salesforce, verify your connected app is set up properly and try again" when clicking Integrate

on your Marketing Cloud API user, here is the exact 2-step fix that worked for me:  

1. Assign the Connected App Permission Set to the User:  

Go to

. Add your CRM integration user here.  

2. Add the User's Profile to the Connected App Policies: 

If your Connected App is set to

, you must explicitly add the user's profile to the app.  

Go to

, and check the box for your integration user's profile.  

Once I completed both of these steps, I went back to Marketing Cloud, hit Integrate, re-entered the username, and it connected instantly! Hope this helps anyone else stuck on this step. 

Good architecture question. Pick the pattern by volume and latency, not by tool first. 

Direction: since the social tool collects the data, decide push vs pull. Push (the tool calls Salesforce) is best for near-real-time — expose a custom Apex REST endpoint or publish to Platform Events. Pull (Salesforce calls the tool on a schedule) suits periodic syncs — a scheduled Apex callout or a Flow HTTP Callout. 

Tool by scale: 

- Low volume / simple: Salesforce Flow with the HTTP Callout action (no code), or a low-code iPaaS like Zapier or Make. 

- Custom logic / medium: Apex (inbound REST resource, or scheduled/queueable callouts outbound). 

- High volume, many systems, heavy transformation: MuleSoft or a similar iPaaS — it absorbs throttling and retries and shields your Salesforce API limits. 

- If the goal is analytics/segmentation rather than CRM records: ingest into Data Cloud instead of core objects, so you do not bloat Accounts and Contacts. 

Best practices you asked about: 

- Auth: Named Credentials plus External Credentials, never hardcode tokens. TikTok's APIs use OAuth 2.0. 

- API limits: batch writes (Composite or Bulk API) instead of one call per record; for outbound respect the 100-callouts-per-transaction limit — move volume to Queueable or Batch Apex with backoff. 

- Sync without duplicates: put the TikTok record id in an External ID field and upsert on it; track a last-sync timestamp for incremental pulls. 

For most social-data cases, a scheduled pull that upserts on an external id, secured by Named Credentials, is the simplest reliable start — reach for MuleSoft or Data Cloud only when volume or unification demands it. 

if this helps, please mark it as the Best Answer so it helps the next person — thanks 🙂

Hey Tony, 

The core fix here is architectural: your Apex REST endpoint should do almost nothing synchronously. Right now, if your handler is doing lead validation, dedup logic, or DML inline before returning a response, that's what's blowing past the 504 threshold under load, real business logic execution easily drifts past 2-3 seconds, which the gateway treats as a dropped connection. 

Recommended pattern: 

1. Inbound Apex REST method only: validates the payload/signature, publishes a Platform Event with the raw data, and returns HTTP 200 immediately. Nothing else happens in that thread. 

2. A separate Platform Event trigger picks up the event asynchronously, does your actual business validation, then enqueues a Queueable job (implementing Queueable, Database.AllowsCallouts if you need outbound calls) to do the real processing/DML. 

3. Cap callouts below Salesforce's 100-per-transaction limit, chain overflow records to a new Queueable automatically rather than dropping them. 

4. If Apex's async queue itself hits a capacity rejection under heavy concurrent load, catch that exception and fall back to a Scheduled job (e.g., retry in ~20 seconds) so nothing gets silently dropped. 

This decouples network response time from your actual processing time entirely, so gateway timeouts stop being a factor regardless of how complex the downstream logic is. Your observation that direct REST calls resolve under 150ms but webhooks spike under concurrency confirms it's specifically the synchronous processing inside the handler causing the bottleneck, not the API layer itself. 

Also worth adding: idempotency (dedupe on a unique payload ID) since Platform Events and async retries can occasionally redeliver, and Named Credentials for any outbound calls so secrets stay out of code.

Hi Dan - the app is Trail Tracker (Salesforce Labs, free on AppExchange). It syncs each user's earned + in-progress badges, points and trailmixes daily via an API integration user, lets you ASSIGN badges/trailmixes, and ships with pre-built reports and dashboards. So 'how many badges/points a user earned' and assigning learning are covered out of the box. 

The specific things you listed are NOT native, though: 

- Available points per badge (earned vs available): it syncs what's earned, not a catalogue of available points - you'd maintain that reference yourself. 

- Alerts when a completed badge is revised or gets new content: no mechanism. Trailhead doesn't surface 'this badge changed' through the sync. 

- Certifications: not synced. Certs aren't badges (they live in a separate system), so it won't pull them - track those manually or via a separate integration. 

- Quests: not a standard synced object either (quests are temporary badge campaigns). 

The upside: Trail Tracker is a Labs app, so you get the objects and code - you can extend it (custom fields for available points, a flow to flag changes, a custom object for certs) rather than build from scratch. Out of the box, though, it's badge/points/trailmix tracking + assignment, not the full picture you're after. 

If this helps, please mark it as the Best Answer so it points the next person the right way - 🙂

Best approach is typically determined by user requirements.

But I would Higly reccommed to go with AppExchange product for this approcah some of the free apps below.

ADL Connect - Free Salesforce - Zendesk Connector

This below comparision will be helpfull

Hi Rangadas - the pattern you describe (works from Postman and Render, but Meta's real webhook to the Site never reaches @HttpPost) almost always comes down to one thing: Salesforce is returning a redirect (a 302), and Meta - unlike Postman or a Render test - does not follow redirects, so the POST body is dropped and your Apex never runs. 

Why the Site redirects, and what to check: 

1. Guest user Apex class access (the most common cause). For a public Site, the Site's guest user profile must have the Apex class explicitly enabled (Site > Public Access Settings > Enabled Apex Class Access > add your class). If it's missing, Salesforce redirects the unauthenticated request toward login (a 302), which Meta silently drops - looking exactly like 'the method didn't execute'. Postman/Render either followed that redirect or you were authenticated, which is why it seemed to work there. 

2. Prove it's a redirect. Hit the exact Site endpoint with curl -i (or Postman with 'follow redirects' turned off): curl -i -X POST

. If you see a 302 with a Location back to a login page, that's your smoking gun. 

3. Exact URL + trailing slash. Make sure Meta calls the full Site path

with no trailing-slash mismatch - Site URL rewriting can 301/302 on canonical differences. 

4. Re-verify the GET handshake against the Site itself. Meta's initial verification is a GET with hub.mode / hub.challenge / hub.verify_token that must echo hub.challenge back. If your class only has @HttpPost, or you only verified while pointed at Render, add an @HttpGet that returns the challenge and re-subscribe against the Site URL. 

5. Respond fast, process async. Meta expects a quick 200; do the heavy work in a Queueable or @future so you don't hit the timeout and trigger retries. 

My money's on #1 - grant the guest user the class and re-test with the redirect-revealing curl. Also confirm the Site is Active and 'Require Secure Connections (HTTPS)' is on. 

Hope that cracks it!