3

My customers are asking for an Integration to update some of their data in Salesforce Marketing Cloud from an application that I own. They want some properties from the users in my application to be added as "data extensions" to their Contacts in SFMC.

My question is: what is the best way to authenticate the user? I've made a similar Integration for Facebook Ads and Google Ads where I upload the users as an audience. This was a simple OAuth flow.

I thought SFMC Auth would be the same. I followed this tutorial: https://developer.salesforce.com/docs/atlas.en-us.mc-app-development.meta/mc-app-development/integration-app-auth-code.htm. It looks all correct, until you click on https://developer.salesforce.com/docs/atlas.en-us.mc-app-development.meta/mc-app-development/access-token-app.htm.

I was under the impression I would make a request for an access_token by providing an authorization_code with the client_secret from the OAuth 2.0 API I registered in my own SFMC account. This seems to be true, but it says in the response, we get back:

rest_instance_url   string  Your tenant’s REST base URL for making REST API calls.
soap_instance_url   string  Your tenant’s SOAP base URL for making SOAP API calls.

This seems like it is returning my OWN tenant base URL. Don't I want the end-user's base URL, so I can make calls on their behalf?

Are API Integrations created in an SFMC account only for use by members of that SFMC account? How do I make an application that allows me to make calls for a user in a different SFMC tenant, how I thought OAuth was supposed to work?

Thanks in advance for any help!

Edit: I forgot to add that an alternative we are considering is making a server-to-server Integration and asking the end user for a client_id and client_secret after they create an Installed Package in their own account. Is this the right way to go?

2

This stuff's a bit murky at the current time. If you're using Server-to-Server workflow, you'll need to capture the ClientID, ClientSecret and Tenant Specific Subdomain from the user and store that somewhere to make API calls to their SFMC instance. The /v2/token route is specific to the tennant.

For the Web and Public App workflow, you also need to know their TSSD in order complete the authorization process and you'll need to have their ClientID and ClientSecret, too, in order to use the refresh token.

This doesn't seem at all intuitive, but Salesforce Marketing Cloud haven't created the newer OAuth workflows with a view to "any" vendor being able to seamlessly integrate their applications with the platform. Rather, if you have your application accepted onto AppExchange, your application can then make use of a consistent Authorize endpoint, clientid and secret that you use for all your tenants. How to list your application on AppExchange, the criteria used to evaluate your app's desirability to Salesforce, the cost to you and the timelines involved are somewhat obscure. Other than apps developed by SFMC themselves, there frankly aren't a lot of Salesforce Partners that have completed the process that weren't strategically picked by Salesforce.

| improve this answer | |
  • Why would you use one over the other? As far as I can tell, it’s to restrict API calls to the permissions granted to the user who authorizes the Integration. If that user leaves the Marketing Cloud organization, are their permissions revoked? – Vishaal Kalwani Feb 13 at 12:41
  • That's correct. The Web and Public App workflow authenticates the user and provides access the Business Units they're granted access to. The Server-to-Server workflow provides an access token that doesn't use the context of your logged in user, but rather that of the installed package. – Macca Feb 14 at 3:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.