Transcript for "API Management in Action: Secure, Socialize, and Monitor Your API's": So thanks again for joining today. We'll give it about a minute for everyone to get sorted so we could reach critical mass. Today's conversation is going to be about API management. And, yeah, we'll get started in about twenty, thirty seconds. Okay. Without further ado, before we get into the actual topic, I just wanted to call out a quick promo that we're running. $50 gift card if you sign up for a demo with Celigo through the whole month of September. It's only open to, new Celigo customers and prospects, so take advantage. Again, this is only running for the next week or two, and it ends in September. The agenda. So we're gonna start with some high level trends over the IT landscape. It's a legal platform, more specifically API management, what some API management challenges are and how they manifest themselves, and then into a demo. We're gonna walk through how you can go about securing, socializing, and monitoring your APIs. So first, a little bit about us. We're an intelligent automation platform. And what that means is we are hyper focused on democratizing access to integrations and doing so with a federated model. So not only is IT building integrations, but also line of business folks can build the processes that they know best. But we're not just focused on application integration. We've over invested in a variety of different integration platforms. So wherever connectivity manifests itself within your organization or within your use cases, you can use Celigo and standardize enough as a platform. And that's whether, you know, you need to integrate with trading partners for document exchange and b two b manager for EDI or what we'll be talking about today, which is where you want to build and manage APIs on this Celigo platform. And this could be for a multitude of reasons. We'll get into what some of these use cases could look like. But imagine that there's some information that resides within your systems, and you wanna expose that information to partners, customers, or some other line of business. So on the left, you see the typical integration and flow related use case. That's mainly system to system data. So it's some sort of business process that traverses multiple applications. Could be your quote to cash, where you're connecting Salesforce and NetSuite, could be lead life cycle management, where you're pushing data from HubSpot to Salesforce. But on the other hand, when you have an API related use case, you're exposing data, systems, processes outside of those systems into external parties, whether those are within your organization or outside of your organization. These are synchronous real time responses. So when an application or a person or a portal calls this API, real time data surface in real time as opposed to a more asynchronous nature of flows. So what's the next few examples here? One, I need to expose a custom API for customers to retrieve their order history, invoice data, or real time shipment tracking from NetSuite or another ERP. I need to expose pricing inventory availability or product catalogs, distributors, or retail partners via API. And maybe my picking system needs to get real time inventory data from my ERP to secure a full order to ensure a full order can be shipped. The main themes here are there's an external party involved that's calling the API that's getting access to data, and they're getting access to that data in real time. So if you are starting to think along those lines or you see something about going about your day to day that has those characteristics, those are the telltale signs that this is an API related use case. Let's go through specifically not just why you would build an API, but when it comes to management, why you should care about managing your APIs and what some of the underlying challenges are. So one, probably the most important, is security and compliance. So implementing things like rate limiting aren't just want to haves. They're essential for your business and for protecting your back end services. You're essentially exposing your systems and applications outside of your organization, and there are a lot of bad actors out there, unfortunately, that could take advantage. So having things like rate limiting in place will protect your own infrastructure and mitigate your risk. Also, there's scalability and performance. So how do you handle spikes in traffic that could be seasonal, and ensure there's reliability, life cycle management, monitoring and analytics. So it's often really hard to understand what's going on with your APIs, how are they performing, how long is the response time, how do I see all that through one pane of glass. And one that's actually not up here is how do I make sure that the APIs that I've built are actually consumed within my organization by developers and customers and partners? Because you could build the most magnificent API in the world, but if no one's using it, that kinda defeats the purpose and it's a lot of work that's gone to waste. So here's a look at API builder. It's not going to be the main part of this demo, but I just wanna understand I want you to understand conceptually how this works. This is our local graphical interface where you can go about building APIs that can then be managed. So you're building APIs within Celigo, you're managing them within Celigo, you never have to leave our platform. But this is more about management. So as we can see here, you've built APIs that are exposing data from core systems. So these are core systems of record, like your ERP and your CRM. Those are what's known as core APIs. Then you string multiple systems together to create a composite service and represent some sort of business process. Those are your business APIs. And then you're exposing that data to some sort of API consumer. But you wanna make sure that there's real security in place. So a gateway over at the top layer before, the information is exposed through some sort of experience, And you see on the bottom left, securing, socializing, and monitoring APIs. So those are paramount and top of mind for the discussion today. And as you can see that that's where the core focus will be. How do we secure, socialize, and monitor APIs that we've created, within Celigo. And now that brings us right to the demo portion. So we're actually going to hop into the platform right now. Alright. So as we can see, this is our home page. Now you see all of our integration tiles. These represent some sort of business process or they could be segmented by department. You're probably familiar with those. But for APIs, we're actually going to go into our resources panel right here and hit APIs. Now let's just click into an API that's already been built so we can get a basic understanding of what's going on here. This is a customer three sixty API. So you can see similar to building a flow, there are lookup steps here to fetch data from Salesforce and Snowflake, but there there are a few nuances. There's an API request node as well as response nodes. The request node is really figuring out what sort of query parameters and, really what's needed to execute on this API request from setting the method to the path parameters to the headers. And then you're mapping the success and error responses down various routes. I just wanted to show you that briefly how you can go about building an API, but, again, the main focus here is on management. So it's as simple as going into the resources tab. We just were looking at the customer three sixty API. Now let's see what this looks like in API management. Now if it wasn't already in API management, we would see the push to API management button. It's that quickly where you can just click and push it right into the management console. But this has already been added, so we'll get the view in API and option. Now you'll notice a few things. The name is inherited from Integrator IO as well as the version and the description. The other option here is you can unpublish and publish the API. As you publish it, it actually becomes available and visible within the API portal, which we'll get into in a bit. Now let's head into documentation. Another great feature here is the open API spec was generated within API builder and pushed right into API management. So you can see it here. You're not having to build your documentation from scratch. You have a basic description. And then the get call here as well as the parameters needed to get access to the data behind this API. Next, we're going to go into plans. So plans serve a few main purposes, but, you can think of them as some form of segmentation. So imagine that you have different customer tiers, for instance, and you want your gold plan could maybe be read access and then your or sorry. Your bronze plan is read access only and your gold plan is read and write access. Or maybe your gold plan also includes more API calls. It's a way to have sort of separate plans and separate users broken out. And within those plans, you can filter by resources available, quota, or rate limiting, and other things like that. Now we're gonna take a jump in and the default is an API key plan for authorization. That's important to know. You can change that or edit it, but that will be available by default. As we step into the policy studio here, we can see the API key plan. But let's say we also wanted to add another policy. So I mentioned before the importance of rate limiting. You can see here how quickly it is to and it would have to, be part of the flows, but how quickly it is to drag in a rate limiting policy, add a description, add the key, and set the number of requests. It's this can be done in, you know, thirty seconds, and it's very quick and efficient. This is, again, going to set the maximum number of requests over a certain time threshold. That way, you can make sure that the back end system stays available and doesn't get, you know, broken down by some sort of DOS attack. Here, you can see I can set the number of requests, so I can put 20 and click save. And it's that easy to configure. Next, we're going to head into the documentation. So if you remember before, the open API spec was already generated. I published the API. Now when we go into the developer portal, this API should be available. Now you see Acme Chocolatiers. That's a fictitious company that we've made. But no matter what, your logo is, we can fully white label this. It'll look like you're branding. And this is an experience that, you can feel confident in exposing to external parties as well, including partners or customers. Now let's search the customer three sixty API, and I can see it right here. Now from this interface, I can edit the description. I'm looking at this from the subscriber's angle or from the customer or partner's angle, But on the back end, I'd be able to change the description, be able to get a look at the OAS documentation that was auto generated. I'd be able to contact the developer or development team behind this API. And then I'd also be able to, go ahead and subscribe to this API. Now if I go backwards, I could test as well. I would just need to add in the the API key right here because we added an API key plan. But this is where you go about subscribing to APIs, sending feedback to developer teams, contacting the developer teams, and ultimately visualizing all of the documentation as well. K? And then finally, some other pieces of interest, when we talk about monitoring APIs. So from the home dashboard, we can see some basic analytics around life cycle status and API state. We can also look through analytics, and we're not running these, but we can see our top APIs. We can see things like top APIs that have failed. We can understand how long the response time is, what errors we're seeing, and click into those errors. So it's really the ability to visualize the performance and the underlying analytics across all of your APIs that are running through our API management solution. So these are the basics of the API management tool. We went through quickly the build before, but securing, socializing through the portal, and then monitoring are really the critical components of API management. And I think we just left the deck, so I'll just run right back to the deck. But let's kinda summarize what we just saw through a quick recap as well as what some of the benefits are. So one is security. So like we mentioned, kind of goes without saying, but once you're exposing this data, you wanna protect those systems. You saw rate limiting. There's also things like quotas. There's everything from JWT to even transformation policies. But security is paramount, and we have all the tools that you need to quickly configure security policies on top of your APIs. Next, socialization. So, again, you have the ability to publish these APIs through branded developer portals, provide really clear documentation, and you can even test from that interface once you add the API key. Monitor. So you can capture real time metrics on usage and error rates. These are things that help you improve your APIs and get better and also, tell you when it might make sense to look into what's going on, double click, and maybe make some alterations to an API if it's not performing in the way that you want it to. So I hope you enjoyed, this presentation. The summary, if you have any questions, you can always reach out to me at chris.furaro@siligo.com. We like to share this slide, because it just shows kind of the scale that we're operating at and some of the use cases that we've grown into, but we're now at the point where we're processing over 40,000,000,000 records per month, auto resolving over 700,000,000 errors. So, proud of the scale that we're able to operate right now and and all the results we're able to enable for customers. But I think this is the one that we're the most proud of. Being the number one iPaaS on g two, it actually needs to be updated seven consecutive quarters now. And the thing about g two is it's actually voted on by customers, and it's really the voice of the customer. So we're very happy to hear that our customers think so highly of us and ready to continue that on that trajectory. Now as far as upcoming events that we want you to be aware of, we do have our connective roadshow in Atlanta on November 5. The connective roadshow is a way for you to not only explore app to app integration use cases, but also understand the full value of our platform. So a deeper version of what I went over today on API management, understanding our EDI solution and b to b manager, and understanding new AI use cases as well. I highly recommend, it's for customers, but it's also for prospects who wanna get a better sense of the value that Celigo could bring to their organization. So come one, come all. If you're in the Atlanta area, if you wanna fly in, we would love to have you. And you can visit that link, siligo.com/connectiveroadshow2025 for more information and to go through the registration process. So thank you very much. I wanna leave some time at the end to go through any questions that you have. So if you do have any questions, please drop them in the chat right now, and I will get to them as soon as possible. Thank you very much. Alright. So we'll give you a few seconds to drop in any questions. I do see a few coming in right now, so I'll get to them in the order that they are received. So there's a question about, where partners would go to access APIs. So partners would go to the development, the API portal that I showed before when we were talking about socializing your APIs. To backtrack a little bit, we automatically generate your OAS spec from API builder. That OAS spec is ported into API management and can be sent right to the developer portal. So you have a base layer of documentation, that you can share with partners. But the portal will not only have that documentation, it'll have a feedback mechanisms that will allow the end user to request access to that API, put in an API key, and then it'll also be completely branded to your own branding. So it'll have a a very native feel to it as well. Another question came in. Am I able to build an API that calls multiple systems? Yes. You are. That's called a composite service. So composite services, can be built in API builder. You can make a call to one system and then just add another lookup step in the flow similar to how you would with an integration flow, and you'd be able to publish out that API. So that's common in use cases where you're building out some sort of process that you wanna expose. So think about a customer three sixty where you're trying to understand customer's behavior across multiple systems of record and multiple touch points. That would be an ideal use case for a composite service. There's a question on rate limiting. So I know I went over it briefly, but rate limiting basically allows you to set the maximum number of API calls over a certain time threshold, and that's ultimately protecting your back end system. Because if you just allowed everyone to go buck wild and make a million API calls at once, that could bring down your back end system and your infrastructure. And that's what's called the DOS attack, and that's what we wanna prevent against. So when we talk about rate limiting, that's really what we're referring to. Are there any other questions that I could answer? I know we do have a few minutes left, so please go ahead, drop them in the chat or the q and a, and we can get to them. One more I see. Would it be possible to expose APIs to internal users? Yes. Short answer is very possible to expose APIs to internal users. In that case, instead of your clients being external, your clients are maybe other lines of business or other stakeholders within your organization. It would work similarly just because you're not exposing it outside of your organization. You are exposing it to other people, and you wanna make sure that that API is secured, socialized, and monitored so you can manage build and manage them at scale. Alright. Well, if there's no more questions, I think we can close things out for today. Thank you again, everyone, for joining. This has been super helpful. As always, you can feel free to reach out to me directly if you have any questions or anything, and then I will, just show you the screen again. We are running a a promo for $50, if you join us for a demo through the month of September. So, please reach out to us if you're interested. Again, that's only running for another week and a half or so, so get a while at less. And, Alexia is reminding me, but the docs tab does have great bonus content. So if you wanna read read up even more about API management, we have a series of blog posts that you can look through and other assets. Alright. Well, thank you everyone. I really appreciate it. And we'll see you again next time.