Salesforce API Fundamentals

– Hello, everyone, thank you for joining I will begin shortly All right Thank you for waiting We’re gonna start now I’m your host, my name is Philippe Ozil, and today, I’m gonna be presenting

Salesforce API fundamentals So welcome everyone from around the world, thank you for joining Good morning, good evening, wherever you are Today’s session is going to be dedicated to Salesforce APIs, and before I jump into the topic of today, I need to give you the Forward-Looking Statement Please remember that we are a publicly traded company Everything that I’m gonna talk about is subject to the Forward-Looking Statement This means that you need to make your purchasing decisions based on what is commercially available in the product today and I will be talking about some things that are future, so be mindful of that That being said, here is our agenda for today We’re gonna be talking about the Salesforce API landscape, so I’m gonna give you a tour of the most common APIs, I’m gonna talk about the different use cases and their purposes Then, I’m going to deep dive into what are the right APIs for the right jobs I’m going to talk to you about specific things you should be mindful of when picking a specific API for a given task, so that will help you pick the right API, and I will conclude with a section dedicated to looking forward, so that means a tour of the API features or features related to APIs that are gonna come to the platform and around the platform in the future Let’s take our tour of the Salesforce APIs The thing I want to jump into first before even talking about a specific API is things that are common to multiple APIs that are part of the Salesforce platform Now, there are tens of APIs that are available in the Salesforce platform, but they have some things in common, and here, I’ve tried to list all of those The first thing is that all APIs require authentication So there are different authentication methods, but at some point, your authentication ties you to a specific Salesforce user, whether you actually enter some credentials, or whether this is a technical user, or whether it’s OAuth, or something else, you need to be authenticated before accessing those APIs Also because we operate on a multi-tenant environment, we do have some limits on what you can do with the different APIs Now those limits are not always the same, depending on the different APIs that you use, but there are always some limits The reason why we have those limits is that the principle behind multi-tenancy, and the fact that customers share certain hardware among different Salesforce orgs is that whatever you do on your org, it shouldn’t impact the other customers that are on the same hardware on the same servers So these limits are here to guarantee that you won’t do anything stupid to basically slow down everybody’s orgs, to put it simply Now, whatever API you use, these APIs are also specific to your org, and the reality is that these APIs are mapped to metadata of your org, but the metadata of your org is specific to your org, you can customize it, you can add fields, you create new custom objects, you can rename things So those APIs reflect the changes that you apply to your metadata For example, if you create a new custom object, this will create new APIs tied to that custom object Now, finally, one important bit of information regarding use case of APIs is that these APIs are meant to be used generally outside of the Salesforce platform So for example, when you talk about APIs such as REST or the SOAP APIs, they are meant to be accessed by default outside of the platform, meaning that you cannot access them, for example, from within Apex, or Lightning Web components, or Aura There are certain hacks, but I will not discuss those hacks in this presentation Keep in mind that these APIs were meant for integration with third party applications mainly That being said, let’s jump now into the landscape of the APIs So there are many APIs that constitute the Salesforce platform, and this is not even an exhaustive view here, but I have listed the most popular ones here, and today, we’re gonna have to make some choices here We’re not gonna be able to cover all of these APIs, so I’m gonna focus on just a few, which are the ones that you may use the most commonly So we’re gonna focus on the SOAP API, the REST API, custom APIs, which include custom SOAP and REST endpoints, bulk API, streaming API, and the user interface API The other ones, which are specific to industries are Chatter, Analytics, Marketing, our Metadata and Tooling are for more advanced use cases, so they’re

definitely not for everyone So today, for the sake of the session’s time, we’ll have to focus on just what is common for everyone So I’m gonna give you some use cases for those different APIs that I’m gonna talk about, also some limits, the advantage and the power of these different APIs So let’s start with SOAP and REST These are really the most commonly used APIs because most of the integrations we have use them So I’d say it’s about 90% of what we do here, and generally there are two main use cases for using those APIs The first and most obvious one is for CRUD operation CRUD means Create, Read, Update, Delete, or it can also be Upsert So this is what you would do to manipulate records basically Then you can also have some search capabilities, and here we have access to our two query languages, which is SOQL and SOSL, so SOQL is Salesforce Object Query Language, which is similar to SQL for other platforms, and SOSL, which is Salesforce Object Search Language, which is another query language which is more text-based, if you’re searching for text in multiple records So these two query languages are supported by the REST and SOAP APIs, and these are commonly used again, by those APIs Now, these two APIs are nearly identical There are certain differences, there are, for example, things you can only do with SOAP, or things you can only do with REST, but most of the functionalities they have are common Now, one thing that is very specific to each API is the format of the APIs, and this actually leads to separate use cases For example, SOAP is traditionally used for doing server to server integrations, because a lot of software allows you to automatically generate features based on the web service descriptor, WSDL, and that’s very common to integrate with another software; however, when you want to build user interfaces for clients, you tend to use REST, because REST is simpler and it supports multiple formats including JSON, which is way easier to parse when you’re doing anything that is web related basically So keep in mind those two things because, for example, SOAP doesn’t have any JSON support SOAP is XML only Now, from my experience, we tend to use mostly REST, but there are certain use cases where SOAP is also useful Now these are the two most common APIs, they’re great, they’re really good, but they have some limits, so you have to take this into account, and I will talk about certain specific use cases which cannot be covered by those APIs later Now there are a whole range of APIs that are available to manipulate all sorts of record types and objects, but sometimes, you don’t have enough with the basic APIs here So what we have enabled since some time is the capability for developers to create custom endpoints written in Apex, and we have exposed a set of specific annotations which lets you create your own endpoints, whether it’s for SOAP or REST That’s pretty powerful, because you can write whatever you want in terms of business logic behind this as long as it doesn’t take too long to respond, you can fit a lot of things here Now one drawback of creating custom REST and SOAP endpoints is that this implies maintenance, and I’m gonna propose to you an alternative to custom REST and SOAP endpoints later on with the Composite API, and you’ll see why sometimes it’s better to actually chain multiple API calls instead of writing your own endpoint, because the code that you write is code that you’ll have to maintain over time, so be mindful of that Here, I’ve given you an example of a REST endpoint, I’ll get back to that later on when I do the demo of this particular feature Now, I mentioned Composite API just earlier That’s something that’s specific to REST API and that is very powerful It allows you to chain multiple REST API calls inside a single HTTP request So you can add up to 25 calls inside a single HTTP call, and in those 25 calls, we can make up to 5 queries whether it’s SOQL, SOSL or other types of queries That’s great, because even if you do 25 API calls in that single request, it only counts as one API call because it’s only one HTTP request So it’s a great way to limit your API limit consumption It also has a way better performance, because instead of doing 25 round trips to the server, you’re only doing one, so the traffic on the network is way lower, and the response time is better So that’s something, also, that is very convenient, and I think that the Composite API isn’t visible enough,

so I hope that if you take something from this session, remember this Composite API, because it’s very powerful There is also another API that doesn’t get enough credit I think that is also very powerful, it’s called the User Interface API, or the UI API in short That’s something that is powerful because it allows you to return a lot of things with a single HTTP request or a single call This API, by the way, is based on the REST system, and it allows you to get in one REST call metadata and data together So depending on what you’re doing, for example, you can get object properties, field properties, layout information, or even this view information combined with records or lists of records depending on what type of API you’re calling, and this is great when you want to create custom user interfaces, because the data that is returned by those API calls is the result of administration configurations So, for example, if you’re customizing your record view, you’re gonna call the same User Interface API, but you’ll get different responses depending on your layout configuration, or, for example, if you query a list, depending on what your admin or users have configured in your list view, you’ll get specific columns or record information depending on filters and columns that are displayed So this is very powerful because these different endpoints can be customized after being deployed based on the admin work That’s it for the first round of APIs We’re gonna jump now into a demo, and I’m gonna talk to you about these different APIs and show you how they work in action So for that, I’m gonna jump to something else I’m gonna jump to my Postman client here Postman is a little tool here which is very convenient when testing HTTP requests, basically So it’s very good for REST Today, I’m gonna show you all sorts of REST APIs I’m not gonna show SOAP, SOAP could be tested also with Postman, but here, I’m gonna focus solely on REST for the sake of time Now, before launching this Trailhead Live session, what I did is that I authenticated against the Salesforce platform and I fired this specific request here, which also has a set of pre-entered properties I’m not gonna show you those values, because they’re credentials, but basically I have requested an OAuth token, and I’ve sent a bunch of information like a password, a client ID, a client secret, which is mapped to a Salesforce connected application With that, I got back a access token that I’m gonna reuse across my different API calls Now let’s jump into our API calls So the first API call that we’re gonna do today is a REST API call which allows us to retrieve a specific record, and you’ll notice that the first thing you have here is the instance domain So this is a variable here that is in Postman It is mapped to my particular demonstration org, which is a developer edition in particular, and then the rest of the structure here is getting deferred to my specific REST endpoint One thing that is important is that these REST APIs are versioned So here I have another parameter which is mapped to version 47, which is the currently deployed version which is Winter 20, and we’re gonna switch over to Spring We can switch up to number 48 which is for Spring 20 Now I’m looking into S Objects, which are my different objects deployed on my org, and I’m receiving an account object with the specific ID This is an HTTP GET request, and I’ve preconfigured a set of headers Now this one here is really important, that is my authorization, and it’s mapped to a variable here which contains the access token that I got when I authenticated, and the other one is just a type of my request Now if I send this particular request, it’s gonna hit my Salesforce org, and you can see here down there in the results that we have some object information, and you can see there are a lot of different things here which are mapped to actually my record here All of that is the information that is retrieved from the Salesforce org Now these fields here are permissions, and the access to the object, this particular record, is also permissions Because I’m authenticated, I’m mapped to a specific Salesforce user which has it’s own properties, it’s own field level security, it’s own permission set, profiles, and so the result of the APIs here are mapped and transformed accordingly to the

access rights that I have to view this particular record In my case, I’m an admin, so I can view anything, but keep in mind that on top of being authenticated, API calls are also subject to restrictions in terms of access rights So that’s the first API call I wanted to show you That’s the most basic thing you can do, retrieve a record from it’s ID, so here we have the object type, and then the record ID Now let’s get into another use case I mentioned that you can also do queries, and here, that’s another API call, which is hitting one of our endpoints here called a query endpoint This is the most simple way to perform a REST query, or SOQL query, sorry, and what you’ll see here is that you have a q parameter which is mapped to a query, and here you have your query Now, the little plus here means that it’s URL encoded, and these are normally spaces, but once I’ve entered those in a URL, they’re transformed to be in the query So this is just a simple query that will return ID and names from accounts, and it’s gonna fetch a range of accounts Now there is a limit to the number of records that I can get This particular org is not fully, not full of accounts, so I’m not gonna hit that limit, but remember that different API calls may or may not be paginated, and in particular, this one is So in that case, I was able to retrieve all results, but if I had more than 1000 records here, I would not see the full list, and you would see that this done flag would be set to false meaning that I would have to query for some more records in subsequent API calls So here, that’s just a list of our different records You can see the names and IDs of those different accounts there So that’s for reading Now as I hit those APIs, I’m going to consume some limits Now one of the very useful API calls that we can make here is to retrieve the limits This is another endpoint here which is gonna tell me about my limits and the consumption of those limits Now there are a lot of limits on the platform We have generally high numbers, but they are used for different purposes, and so if you scroll down, you’ll se various features, including the daily API requests, and you’ll see that I made a couple of tests today, and I don’t have my full API count The more API calls you make, the lower this remaining number will be, and at some point, it’ll be reset Now, depending on the different API calls, you’ll have different limits, and when you hit zero, you’ll get some errors, and that’s going to be a problem I’m gonna talk more about those limits and the design considerations behind those later on in the presentation So far, we’ve seen three different REST requests, which are all GET requests that allow you to view data, but what if I want to modify data? What if I want to call a custom REST endpoint? Well, let’s jump into the next one The next one here allows us to call a custom REST endpoint, and the way you can see that is it’s mapped to this Apex REST URL path here with something behind Now the hello here is something custom It’s not part of the standard APIs, and this is actually calling a custom code here that is displaying on my screen now, which is based on Apex This is a custom Apex endpoint, and this is created with a few annotations The first one here is RestResource This one here is declaring a custom endpoint, and it has an attribute here called urlMapping The /hello here is what ties it to the URL I saw just before out in Postman, and then for this particular CustomREST class, I have several global static methods, here I only have one for POST, which are annotated with specific extensions Now when I’m gonna do a POST on this particular URL, I’m gonna call this particular method, and I’m gonna check for these particular parameters, so I’m gonna return just a string In this particular instance, saying “Hello name” Let’s check it out If I go back now in my Postman definition, if I look at my body here, I’ve already entered a body in JSON, and I’ve provided name, which is Trailblazers So if I send that request, I’ll get a simple response, “Hello Trailblazers” This is a really rudimentary call here, but you can do a lot of logic and call other Apex classes, and you can do a lot of processing with that, and sometimes you can just use the basic API, so you can go further with those custom endpoints,

so you can create a lot of logic there Do be mindful, however, of one thing All the calls that are happening are, by default, in the same transaction, so there is a limited amount of time for which this particular request can be processed Here, this one was almost instant, but as you add on a lot of logic behind, it can take a lot of time, and if you exceed the default 30 seconds, there’s a chance that the request will timeout, and it will not proceed So that’s another thing to consider when creating custom endpoints Now we’ve seen basic API calls, now let’s talk about Composite APIs Now if you recall what I said earlier, the Composite API allows you to chain multiple API calls, so how does that work? Here, I’m hitting the Composite API endpoint, and let’s take a look at our body Now our body is written in JSON, and at the first level here we have an array This is an array of different API calls, and there are actually two API calls in this particular definition here The first one is a POST that will actually create an account object that is named “Sample Account.” It will save the reference of this newly created account into a reference called “refAccount”, and then the second request is also a POST that is going to create a contact object It’s gonna name it “Sample Contact”, and what is super interesting here is that it’s going to use the reference to the account that was created earlier and attach it to this particular account So to sum it up, we’re creating an account, and we’re creating a contact, and this contact is going to automatically be assigned to this particular account So that’s pretty powerful because here, we have done the equivalent of two different API calls, creating the account and creating the contact, but we’re only counting one single limit here, because it’s only one request Let’s check it out So I’m gonna click on send here, and this is gonna execute my two API calls, and if you look now at the results, you’re gonna see individual results here for the different API calls The first result here which is success with the account ID, and you can see, we also have a link to directly access our account object, and the second result for the second part of the operation, creating the contact Did it work really, or is it just me faking it? Let’s check it out Now if we jump to our org, let me close that for a sec If we jump to our org, we’re gonna see if we can find this sample contact with it’s account Here you go So we have the sample account with the sample contact that we just created, and if you look at the details here, you’ll see that this has just happened right now if you look at the creation date This just happened now So that’s how we can use the Composite API to chain multiple calls and reduce your API consumption One more example before I finish this first demo, I wanna show you one last thing That is the UI API, the User Interface API There are multiple APIs that are part of this category here, and I’m just gonna show you one today which is called the Record UI, and this is mapped to a specific record which is an account if I remember well, and when I hit that, it’s gonna give me all sorts of information, so this is a very very big call that we are making, and I’m gonna minimize a bit the content of this particular call, because there’s a lot of information behind it What this does, you can see it’s almost 10,000 lines here, so there is a lot of data that has been returned, and it’s a mix of metadata and data Everything you need to create a record view, basically Everything that Salesforce uses each time you click on the record view They’re information about the current states of the layout, which particular sections of the layout are expanded or visible Then there’s all sorts of information regarding layouts So here, we’re looking at the layouts of the account object, and we can see the full layout with the different sections, and even down to the name of the different fields and their configurations Finally, we have the object information with the different fields, the relationships, and you can see all the details of the different fields, and one last thing you have which is probably the most important, is the data of it is mapped to this particular account ID and it’s different field values that you can see here,

the ID, the name, etc. etc So all of that information is returned into a single API call, and it’s critical because this allows you to render the full view in lining experience based on this information So if you were to recreate a record view in a third party application, you can call the UI API instead of having ten different calls, one call for example, to retrieve layout, another call to retrieve the different fields, and then another call to retrieve the record data Now you don’t need to do all of that Just a single UI API call, and you get all that data wrapped up You’re not necessarily gonna use all this information, but it’s a single call, and you can exploit all of that to render it Not only that, you can call this specific API and benefit from the flexibility of the administration configuration So if the admin later changes the layout of the object, the UI API calls will take that into account and will add or remove custom fields depending on whatever the admin has configured for this specific layout that we’re looking at So that’s a lot, but that’s it for the first round of demos We saw the REST API, we saw custom endpoints to the REST API, Composite, and UI API Let’s now jump back to the slides So these are really the most common APIs that you can use, but there are others, and let’s talk now about the Bulk API Now I mentioned there are certain limits to the number of API calls you can make, and also the number of records you can return per-API call Now sometimes we have very large amounts of data that you want to retrieve, you can be tempted to still do that via REST, but if you force yourself to use REST, and you hit too many records, you’re gonna hit some limits, and you’re gonna get errors So that’s why we introduced the Bulk API The Bulk API allows you to work on a large number of records, and when I say large, I mean super large, I mean tens of thousands, I mean hundreds of thousands, and even millions of records The cap of this, for instance, is 100 million records per 24 hours That is a lot of records, and I doubt you’ll hit that limit, but some orgs do hit that limit So anyway, that’s really high limit, and this API is optimized to work with these large data numbers One thing that is specific to this API is the format that it uses It’s operated with the REST or SOAP API, but the data that is provided with this particular API has to be with CSV format, and for those of you who were around in the ecosystem for some time, I’m going to talk more about the version 2 of the Bulk API There was a previous version, but today I’m gonna focus more on version 2, which is the currently supported NGA version of the Bulk API Now whether you’re using version 1 or version 2 of the API, this API works with a large number of data, and has a constraint, it’s not realtime, it is asynchronous, meaning that you’re gonna start a job to retrieve some data, and the API will return immediately to you It’s not gonna wait for the end of the job You’ll have to get back later to retrieve the result of the job Now this job can take hours to complete if you’re returning hundreds or thousands, hundreds of thousands of records, it will take some time, and this is why this API is asynchronous It needs some time to process all the records you wanna work with So more on that on the next slide Main use cases for the Bulk API, well it’s when you have to process large numbers of records, and it’s very good for batch processing, so when you have to do a lot of Create Read Update or Delete operations for vast amounts of data It’s also very good if you want to extract and synchronize your data with third party applications So for example, if you want to do some analytics on the third party platform, you need a snapshot of all your accounts or all your leads, you can use the Bulk API to extract all of this information in a specific database so that you can run a lot of analytics on that data outside of the platform for example It’s also good if you want to do some backups So if you want to backup your org outside of Salesforce, you can also use the Bulk API to do that, and some of our partners do that, so they have to use the Bulk API because retrieving all the records is quite intense Now let’s jump into how this works I mentioned that the API is asynchronous, so how does it work? Well the Bulk API works with three different calls, and here I’m really talking about version 2 The first API call that you will make will configure and start a job So you’re gonna tell Salesforce what kind of record you want to work with, and what other operations you want to perform on this particular record, for example, some data that you want to insert

and some constraints for that Then this is going to start the job The job is gonna be working on the platform, but the API will return instantly that it has started the job if everything goes well At this point, the job is processing It can take hours, again, so you’ll have to query back for the status of the job This can be done several times, and at some point the job will be failed, in progress, or even completed, and if the job is completed, you can then call the third API call to retrieve the results of that particular job So remember that this operation can span across several hours So it’s not something that is instant, so it’s very good when you have time, it’s not something that is realtime at all Let’s see in practice, an example of the Bulk API now So I’m gonna jump again to my Postman client here, and we’re gonna explore the Bulk API version 2 if I can get my mouse back That’s interesting, my mouse just disappeared All right, anyway That’s gonna be painful I’ll try to do that with a keyboard So the first thing we need to do is to specify a job, and what we’re seeing here is that there’s a POST URL jobs/ingest and I really need my mouse back, sorry Let me just kill the presentation for a sec There we go So We’re gonna call this first API endpoint to create a job, and what this is doing is that it’s passing some parameters in the body Now because we’re actually creating several requests, this is called multi-part, it’s a way to group several HTTP queries inside a single query, and as you can see here, we have this boundary tag here which indicates we have two different queries here So each query has their different headers and their bodies Now the first query is the query that creates the job The query is gonna operate on the contact object The format of this particular Bulk API call is CSV which is the default, comma separated values, and the operation that we’re gonna perform is an insert operation Now, a single Bulk API call is only for one object and one operation If you wanna do multiple objects and multiple operations, you have to divide that into multiple Bulk API jobs Now, after the boundaries here is the definition of my data that is going to be processed in my job, and you can see here, which is the content of my Bulk API specified in CSV, comma separated values Now we can have different options, so it’s not necessarily comma, it can be semicolons, it can be tabs, there are multiple formatting options, but the idea is that there is a delimiter, and we have those different values Now this is a very simple example I only have three rows that I’m inserting The first line here are the columns or the field names, first name, last name, and title for my contact object, and the values down there So that’s not an ideal use case for the Bulk API If you just insert three objects, or three records, sorry, you wouldn’t use the Bulk API, but here, I’m gonna stick to that just for the purpose of the demo So that’s how it works Multiple queries First part of the query is defining your job, and the second part is specifying the data that is being processed in your job So if everything goes well, I’m gonna insert three different contacts, mapping those different field values here So that’s the first part of the operation I’m gonna send that, it’s gonna configure my job, and then it’s gonna start it So I’m gonna send this, and you can see here in the result that my operation is uploaded, and the job is starting Now, the next step is to check the job status So this is pretty quick Oops, sorry, I forgot one thing After creating the job, I got back an ID here I’m gonna copy that job ID, and I need to use that for the next API call to get the job status, and in here, I replace this particular variable here with the job ID so that we get the job status for my particular job that I just created So then I can query it, and you can see, this is our insert contact job that we just did, and it’s actually already completed I took too long to just check that, but creating three records is almost instant, so that’s okay Now there can be multiple states The job can be in progress or it can be completed In this particular instance, it is completed So we jump now to our third and final call to get the success results So here again, I need to replace the job ID here

with my job ID, and then I have multiple options here in this particular part Here I’m only gonna look at the successful results, but there are other endpoints here for the failed results or the unprocessed results, depending on how complex your operation is, there’s a chance that some of your records can’t be updated, so you’ll need to query those different endpoints to check the different results So I’m going to call that and here we can see the different IDs of our different contact records that were created, and we can see that everything went fine Let’s just check it out by using the org data So if you’ll go now into Contacts, and if I look for Bulk in the Actually I should be looking in all contacts and filter that with Bulk Oops, sorry Anyway, you get the point They were here Yep Here they are, the three different records that were inserted over the Bulk API So very empty of course, but you get the point of how we can use the Bulk API to create multiple records Now, again, you can use that for Create, Read, Update, Delete So that’s it for the Bulk API, let’s go back to the slides, and of course I’d closed my presentation, so I need to open it again There we go, so that’s the Bulk API Now one more API before I move on to the next section, the streaming APIs and it’s actually more than one API It’s a set of four different APIs We talk generally about the streaming API, but the truth is there are four different versions of those APIs, and they’ve been introduced gradually to the platform So today I’m gonna talk mainly about the current ones, but know that what we used to call the streaming API was something that is a bit legacy So there are four APIs The first one that was introduced is called the Generic API, and then there was the PushTopic I’m not gonna talk about those Consider those legacy There is no innovation on those There is still support, but we’re not investing in those, because we have two new APIs, which are the current generation of streaming APIs which are still being developed and have new features for each release The main one, the first one that was introduced in the second wave is called Platform Events, and the second one is called Change Data Capture So Platform Events allow you basically to create messages that you can send to external systems or send and receive with external systems and Change Data Capture or events that react to data change, basically Now all of these different streaming APIs use the same underlying technology which is based on PUSH and allows us to broadcast platform from within the Salesforce platform The type of architecture here is called a publisher/subscriber model This is not something that Salesforce invented It’s based on third party technology, but it’s pretty powerful because it’s broadcast, and it is realtime, or I should say almost realtime Typical use cases for those streaming APIs are to build realtime applications, create mobile applications, or synchronize data with external systems, because it’s particularly interesting when you have Change Data Capture to react to change Now let me just quickly jump over the publisher/subscriber models, which you can understand how this works Inside the Salesforce platform, we have something called the enterprise messaging bus, and this is where all the different event definitions live, or I should say events or messages, which is kind of the same thing here On one side, we have event producers, the ones that are gonna send the messages, and on the other side, we have event consumers The way it works is that event consumers are subscribed to a specific type of message and the event producers are gonna publish a message Now the event producer publishes a message to the bus, and the bus will broadcast the message to all the registered consumers Now, what is interesting about this particular architecture is that consumers are not directly connected to the producer They only know about the bus here Same thing for the producer The producer does not know about the consumers, and this kind of decoupling is quite powerful because it allows us to do applications that scale So I could give you a whole talk just on this particular subject, and in fact, I already did a present a few sessions, so if you’re interested in learning more about the streaming APIs I advise that you look on the Salesforce blog, or on our different video channels There’s a lot more resources on that specific subject

I am not gonna give you a demo of those, sorry, for sake of time, we’re running a bit late, so we’re gonna skip that demo for today, and I’m gonna jump now to the next section of my presentation talking about the different types of API and how you define which API to use for which particular type of job So first, let’s go back to how you create an application How you manage an application, what is it’s lifecycle So when you create an application, it’s a combination of different phases The first one is the plan phase, and you would expect that this is the time where you actually draw up your specification and figure out what kind of APIs you’re going to use to implement your application So that’s right, this is where you figure out what kind of application you use, and what kind of APIs you use After that, you code it, so you implement useful APIs, integrated with all the systems, and you do user integration testing, and also technical tests, and finally you release and monitor Now the two steps here that are vital for APIs are the planning phase, and also the release and monitoring phase, and this is really important because delivering an application that works is not enough You also need to make sure that this application works, and that it works for a long time So I’m gonna talk about those two specific phases in this particular section, because these are really where you have to focus your efforts when you talk about APIs So how do you figure out what kind of API to use for a given use case? Well there’s a set of different factors that will guide you to pick an API or another The first one is the user experience that you want to deliver Is it something that is desktop only? Is it something that is mobile? So the form factor plays a huge role in that particular aspect Also what matters to the end user? Is it something that is gonna be dynamic? Or is it something that is gonna be static? Also what are the objects and records that you’re gonna use? Is it always the same object and always the same records? Are these objects and records static, or very likely to change, or you’re gonna add new fields, remove fields? What are the permissions to access the different records? Do you have different user profiles, for example? So these are really important questions Same thing for operations Are you gonna work with large data volumes? Are you gonna work in offline mode for example? These are really important questions to ask Now this is true when you’re in the design phase, but one thing that is often overlooked when you create an application and choose an API is how will your application grow and scale? Because you can deliver something that works on the first day, but maybe your company is gonna grow, maybe you’re gonna have more users using your application, and maybe other teams are gonna implement other features on the platform, and your app is gonna share some resource consumption with other apps on the platform In the end, maybe you didn’t choose the right technology, so you’re gonna hit the last thing, limits So that’s something that is often overlooked when choosing an implementation You tend to go for the shortest path to deliver something that works, but be careful not to be near-sighted, because you have to think about growth and scale, about how your app is likely to be used in the future So that takes a bit of guesswork, but generally, it can save you a lot of headaches when you plan to use the right APIs from the start So really, that’s important, that’s the last one Make sure you pay attention to the type of limits your resources, or your apps are consuming And there are different types of limits that you can use, and the ones that are the most common are the number of API requests you make per day, for example, or also the number of records that you are receiving for each of these API calls For example, maybe you’re gonna work on a query which loads 10 different records, and it’s always the same 10 records, there’s no problem, it’s not gonna grow today, that’s fine, but maybe tomorrow, your company is gonna acquire another company, maybe there’s gonna be thousands of other records in this particular category, and maybe you’re gonna hit limits, maybe you should’ve implemented pagination, for instance, instead of just making sure you got those 10 results as always So these are factors you need to take in account, the amount of resources that your API are consuming may be different, so that’s something you have to budget, and you’ll also have to take into consideration the fact that other apps are gonna be added to the ecosystem So that’s something you need to monitor Again, to sum it up, think about long term growth It works today, that’s fine, but will it scale tomorrow? Is it something that’s gonna work tomorrow, and what is the cost for today? If you work a bit more, use another API which is maybe a bit more complex to handle, rather than fixing something in some sort of

emergency mode when the thing is burning and you have hit the limit So that’s something that you really have to think of Consider it cost-wise, and finally, the last piece of advice I wanna give you is that it’s not because it works today, but it’s gonna work tomorrow, so you want to make sure that you monitor the consumption of those limits from day to day or over time so that you’re not gonna hit the API limits errors, because once it happens, it’s gonna be very hairy, because it’s gonna impact all of your different applications So you want to know in advance that you’re getting near your limit to start a project to refactor your applications before it’s too late So that’s really critical here Looking forward So we saw the different APIs and there are plenty of those, but sometimes you need even more, and sometimes you need to integrate with third party systems With that, you can use the power of MuleSoft to integrate the Salesforce platform with external systems You can also use that to unify your data, so you can mix and match external APIs with Salesforce APIs, and you can even create your own custom endpoints So that can also be an alternative to custom REST and Apex endpoints That’s actually pretty powerful here I was supposed to give you a demo I’m gonna take a few minutes, I’m probably gonna end late, but I’m gonna take a few minutes just to show you how you can quickly create an endpoint with MuleSoft Let me just do that now I’m gonna switch to my browser here I’m gonna show you a quick example of how we can use the power of MuleSoft Here, I have my MuleSoft environment Sorry, I just need to reopen my flow designer, and I will show you very quickly how you can create a custom API endpoint with just a set of clicks So this was supposed to be open before, I apologize for the delay It takes a bit of time to load first And in a few seconds, we’re gonna be seeing our API Okay, this is not the one I wanted to show you, sorry I’ll need to go back to my list, sorry That’s the one I want to show you, Sample APIs Bear with me a few seconds So in this particular example, I’ve created a simple endpoint that I can call, and this is just an HTTP endpoint with /hello, and the MuleSoft endpoint designer is just based on clicks So the way it works is that you can add cards, and you can chain them pretty much like you can build a process or a flow in Salesforce The first card here creates a HTTP listener, but it’s gonna be deployed on a server, and if I hit with a POST request to this particular /hello endpoint, this is gonna take some data in, and pass it to the next card Now this next card is called data weave, and it’s a way to transform data Now, my first call here was taking a name parameter, and I’m injecting that into something that is another payload, so I’m transforming this data into something else, and in this instance, what I’m doing here is I’m adding a few other fields like a name and a site, and I’m creating basically a Salesforce account So I’m just transforming this data with sample drag and drop pre-entered values and dynamic values, like for example, this name here is an expression that maps hello with the name that was provided by my previous call, the HTTP input from the other request Finally, here, I’m using another tile here which is a connector Now the MuleSoft is great because it’s shipped with a whole range of connectors which are pre-built This particular connector integrates with Salesforce REST APIs and allows you to create records There are other connectors with other third party applications, so for example, if you want to send an SMS, you can use another application to fire an SMS If you want to call Tableau integration, you can do that If you want to call any third party application, you can even create your own connectors, and this is just very simple to use because I just have to input the type of record I want to create, and provide values for those records Here, I just take in the account that I have input in the previous tile, and just insert that record here Now if I deploy and test my, oh All right, sorry I think I’m not gonna be able to demo this, but anyway, the idea here was that

I was supposed to create a custom endpoint, but I could call and, with the use of POST, I could show you how I can create a custom account just by hitting this custom API Now this is a very straightforward path, but you can imagine that you can add more tiles here, and you can group multiple system calls before calling Salesforce You can create your own APIs with the power of MuleSoft All right, back to the slides, and we need to finish I’m late, sorry for that So the last thing I wanted to show you before closing the call, the session here, was the future The future was announced at Dream Force, and it’s called Evergreen What this is essentially is serverless, or the fact that you can deploy something called functions on an elastic environment, and this allows you to call code, but it is no longer running on Salesforce platform, but is deployed in an elastic serverless environment, and there are multiple environments that are planned to come to life later this year You can run code on NodeJS, Java, or Apex for instance, and this is gonna be natively integrated with platforms, so you do not have to worry about authentication, you don’t have to worry about passing on context, and you can all those different things from different points within the Salesforce platform For example, you can use a Streaming API with Change Data Capture or Platform Events, call also those functions within User Interface with Lightning Web Components, or even Flow Builder or Apex Now this is the theory, let me show you a very practical use case so that you can see the value of those functions So let’s take some Apex code running on your org, and you’re gonna call a function called generateInvoice(), this is gonna call your Evergreen function, which is running on NoneJS, it has a generatePDF() function, and this is gonna call a third party library that is available on NodeJS to generate that PDF, and it’s gonna return it back to Apex So you can see here that without having to manipulate Without having to do all of these integrations, you’re gonna be able to call applications or libraries built with third party technologies very easily, and all of that, the value of Evergreen in functions is that all of that is going to be seamless, and everything that is running on NodeJS will not consume API calls because it’s running on a different environment, which is elastic, and it is working as functions as a service It’s no longer something that is on a multi-tenant environment, that is license based with governor limits, for instance So that’s a whole different model, and also revolutionized the way we think about API consumptions and limits That’s really the future So stay tuned for that, it’s not fit for tomorrow, it’s gonna happen gradually this year, and we should see the first versions available to beta and pilot later on during the year With that, I need to conclude now, so I think I gave you a whole tour of the most commonly used APIs and gave you specific use case limits Advantages and drawbacks of specific APIs I’ve given you an overview about how to plan ahead and pick the right APIs for the right type of jobs, whether you’re going to use them in a specific way or not I also gave you another piece of advice, which was don’t rest on your laurels once you have created an application, make sure that you monitor it’s consumption over time so that you don’t get any bad surprises when you hit limits Finally, stay tuned for product updates, in particular about Evergreen This is gonna be big, so you’re gonna hear a lot of it, a lot of updates before and after Trailahead EX which is coming later on this year So hopefully it’ll be available for you to test soon With that, thank you You can take a look for some information and resources online We have a lot of information on the different APIs One of the best things you can do is look at the different developer guides There are developer guides for each and every API, so specifically developer guides for SOAP, REST, Bulk, UI, etc There’s also a very good tried module that you really want to do, it’s quite short, well no, it’s not quite short, it takes two hours, but it’s the Lightning Platform API Basics, and this is a condensed tour of all the different APIs that are named in this particular session, and you get to play with those APIs, and you can see how they work in virtual environments So that’s really something I recommend Finally, there’s also an interesting resource on help and more which lets you compare the different APIs, it’s called “Which API Do I Use?”

And it’s a goldmine when you compare the different APIs So it tells you about the different protocols, how different APIs work in comparison with each other, and it’s also a good pointer to the different documentation With that, I’d like to thank you again for tuning in, and sorry for ending up a bit late I hope you learned a lot of things, and don’t hesitate to give me feedback if you want I’m Philippe Ozil, the Principal Developer Evangelist with Salesforce Thank you again for listening Have a great night and a good day Bye