Re: How to get the Custom Service display name on the REST API

Anonymous
Not applicable

How to get the Custom Service display name on the REST API

Hi everyone,

In order to identify, on my integration, which "Customer Service" the user is connected to, it would be great to have the "Display Name" available for consumption at API level.

E.G

When calling the /identity/oauth/token end point to get the authentication token it would be fantastic to have the customServiceName property

Is that available somewhere else?

Here my example

{

access_token: "........",

token_type: ".........",

expires_in: 3367,

scope: "......",

customServiceName: "My Display Name Value"

}

Screenshot_11.png

Bests!

5 REPLIES 5
Drew_Loika
Level 2

Re: How to get the Custom Service display name on the REST API

Having access to this value would significantly improve our user experience. Is it something Marketo can provide?

Best,

Drew Loika

Product Manager - Cloud

Tableau

SanfordWhiteman
Level 10 - Community Moderator

Re: How to get the Custom Service display name on the REST API

Well, the display name can be easily changed, so you can't rely on it for any kind of accounting. I see where cosmetically it could be useful, yet there's no telling which custom service that friendly name is assigned to at a given point in time. Only the Client Id and Client Secret are guaranteed to persist over the lifetime of the service.

If you want cosmetic information that you can later read, try Base64-encoding it in the email address of the API-Only User that you request from the client. That address isn't used for any other purpose, and is less likely to be tampered with than the display name (though it's still possible). TXkgQ3VzdG9tIEFQSSBVc2Vy@example.com = "My Custom API User".

Drew_Loika
Level 2

Re: How to get the Custom Service display name on the REST API

Thanks for suggesting a workaround. The goal here is a user-friendly default name when establishing a connection to API. Say I have two Marketo instances, or for some reason (different permission scope?) I have two custom services, how can I tell the difference between them? Sure the client id and secret are meaningful to a computer, but they're not to me when I'm trying to easily determine what I'm connected to.

Anonymous
Not applicable

Re: How to get the Custom Service display name on the REST API

Hi Sanford, thanks for your suggestions.

There are some important points here to consider:

  • we won't have any control over the custom service, only the application users will, we only provide an "adaptor"
  • the application users might have insufficient technical knowledge to instruct them to create a Base64 encoded local-part, and specially the resulting Base64 string might be broken
  • Once the user retrieves the data, the "Identifier" ( which is only "cosmetic" but important for the UX ) won't be automatically updated anymore, the user can change it manually though, and the original data cannot be recovered.
  • Using the email will also require from us to explain why the email is not used for any other purpose.

In this scenario, IMHO, the user know what service is targeting, and will have a default "identifier" e.g "Marketo - TWDC" , even if the displayName change it won't be updated on our workbook, it seems more user friendly and won't require any extra technical noise for the user to use it.

Is there an API endpoint to be consumed to retrieve that information? If not, is there another user friendly option we can consume? ( I initially thought about using the subdomain part of the service url (123-ABC-123.mktorest.com) which is immutable, but still ... its not very beautiful )

SanfordWhiteman
Level 10 - Community Moderator

Re: How to get the Custom Service display name on the REST API

There's no method to retrieve anything like this.

I don't really understand what you'd get from reflecting the REST hostname back to the user.  That's going to be the same for every app that connects to a Marketo instance, and by definition you already have it in your config.

Using the email address that is supplied by the user to you should be sufficient, whether or not it has a friendly name encoded in it.  That's the security principal, and it's an address that they chose to assign to the service. If they can't locate the service using that ID afterward, that's on them for not making it unique.  Bottom line: there isn't anything unique except the client credentials.