Use HTTP Callouts in Flow to send SMS via Esendex – Part 1

Those of you that know me, will know that I spent 9 and a half years as Customer Support Manager for Esendex, which is where I got my feet wet with Salesforce. One question that came up from customers that we couldn’t really help with was how to send from Salesforce. It didn’t come up often enough for us to invest in a solution, we generally had to point the customer to the API documentation and send them off to code it themselves. Which at the time would have meant APEX and a developer, now however we have HTTP callout in flow, which I recently used for the first time for another API based issue I needed to resolve, so out of curiosity I set to to see if I could make it work for Esendex.

SPOILER ALERT: I could.

For this I’m using their older API (https://developers.esendex.com/api-reference/#messagedispatcher) this being the one I supported, the newer one may be easier to implement.

Lets get started

The first thing I needed to do was set up a Named Credential and External Credential, but there are some tweaks here that I had to make to accommodate Esendex.

Their API (https://api.esendex.com/v1.0) by default is XML rather than Json, (the json elements were added after the development of it in XML) so we have to add some Custom Headers to tell it that we want to send and receive Json.

External Credential

By default you’ll be taken to the Named Credential tab, but you want to start with the External Credential, because the external is required by the Named.

And External is where the magic happens.

Esendex uses Basic Auth, there is a session endpoint, but its only documented in XML, no json examples listed so I didn’t bother trying, you might want to try, as it is better in terms of security than passing your auth with each request.

Lets get started and give it a name, I’ve named everything as Esendex, so I can find what I want easier.

I used the custom option, as the Basic Authentication option in flow is newer, and I know what I’m doing with it, again you might want to try it.

Then we create a Principal, I’m not a dev, I don’t know why its called principal.

Again I’ve called it Esendex.

Parameter 1 is Username and then the value is the username starred out.

Parameter 2 is Password and then the value is starred out, remember though with Esendex that your portal password is not your API password, you have to set your API password within your profile.

I’ll come back to that piece at the bottom about the permission set, first we need to set up the custom headers we need, there are 3.

  • Authorization
  • Accept
  • Content-Type

These are standard names for headers that you might send, if you tested this in Postman you’d select them from a drop down list, it’d be a nice touch if one day Salesforce added such a list.

First  in the sequence is Authorization

The value for this is a formula, so it ought to look familiar:

{!’Basic ‘ & BASE64ENCODE(BLOB($Credential.Esendex.Username & ‘:’ & $Credential.Esendex.Password))}

Esendex is my principle name

Username and Password at the Name I gave each parameter.

So if you named your principle SendSMS you would use $Credential.SendSMS.Username

That’s going to get you authenticated against Esendex’s API.

Now, do you remember how I said they defaulted to XML, and you need to tell them to use Json, that’s what the next two do, the order didn’t seem to matter, but I did seem to need both in my testing.

Name: Accept Value: application/json

Name: Content-Type Value application/json

So now your screen should look similar to this

Apart from the Related Named Credentials, yours will be blank.

Let sort that now.

Go back to Named Credentials.

Named Credential

You have your entry under External Credentials that we just created, so now on Named Credentials lets hit new

So again I’ve called mine Esendex, then in URL we enter the base URL for their API which is https://api.esendex.com/v1.0

So by entering the Base URL rather than the dispatcher URL we can use this later to do more than just SendSMS if we have the account options, if your account is set up to receive messages you could access your inbox, or most likely you’ll want to check the status of your sent messages.

In the External Credential, you can select the External Credential we just created, see why we did that first?

And most importantly, for that formula to work for the Authentication we need to check Allow Formulas in HTTP Header

It save and that is all the authentication piece set up nearly!

One last thing to do give users access to the Principle via a permission set, so they can sendSMS

So create a new permission set, call it what you will, again I’ve gone with Esendex, so I know what its giving access to.

Then in the Apps section, you are looking for External Credential Principle Access

Click Edit and move your principle from left to right

Save it and now assign it to whomever needs access this included your admins.

In Part 2 we’ll look at how to use the HTTP Callout to access to the Esendex API.

Deleting Case History

Select id from CaseHistory where Case.Account.id = ‘xxxxx’ or Case.Account.ParentId =’xxxxx’

  • Click Setup.
  • Enter User Interface in the Quick Find box and select User Interface.
  • Under the Setup heading, select the “Delete from Field History” and “Delete from Field History Archive” checkbox.
Under the Setup heading, select the "Delete from Field History" and "Delete from Field History Archive" checkbox.
  • Click Save.
  • Now create a permission set and add the following from System Permissions:
  • Enable ‘Delete From Field History’.
  • ​Enable ‘Delete From Field History Archive’.
  • Add the permission set to your user account

Now you will be able to see the CaseHistory object (and other history objects) in your preferred API tool.

Summary

If you want to delete case history you will need to enable access for this.

It is also worth noting that doing so will prevent any history reporting on these cases I could have been more granular in my initial query to filter out status changes or other changes that might be needed. We don’t need these for our reporting, but you might.

5 x Salesforce Certified || 3 X Ranger || Community Group Leader Nottingham Salesforce Admin User Group

Design a site like this with WordPress.com
Get started