Name: API Part 2: Governing and Securing APIs with Celigo API Management
Uploaded: 2025-10-14T16:16:53.123Z
Duration: 49 min 12 s
Description: API Part 2: Governing and Securing APIs with Celigo API Management

Transcript for "API Part 2: Governing and Securing APIs with Celigo API Management": Yeah. We have South America represented, Canada, India. So thank you all for tuning in across the the different time zones. We really appreciate it, and we're looking forward to chatting today. Alright. Another thirty seconds or so, and we'll get going here. K. Perfect. That was about three seconds. So, as a quick background, my name is Chris Farrar. I'm on the product marketing team here, primarily supporting our API management solution. I'll also be joined, when we get to the demo by Jean Carbone, who's one of our leaders in presale solutions engineering. What we'll be talking about today is really best practices as well as a demo when it comes to managing your APIs. So you're you're not only able to build APIs within Celigo platform through API builder, which we chatted about last time. You're also able to secure, socialize, and monitor your APIs to ensure that you have an effective API strategy. And we're going to be touching on all of those phases of API life cycle management and how they can be accomplished within Celigo. So we'll start with a quick refresher on our platform, what really is an API use case, what it could look like in your world, what some challenges are, when folks start to scale out their API management strategy, then how we address those challenges in a demo, and then we're going to end with a recap and q and a. So if you have any questions, comments, concerns, feel free to drop them in the q and a section of the chat, and we promise we will get to them at the end. Alright. So first, I'm sure a lot of you, came to know Celigo through, our app to app or integration capabilities. So you can see application integration all the way on the left. We've kind of moved from, just really the plumbing to a fully fledged platform that can address whatever integration patterns are thrown your way. So things like b to b manager for EDI. So you can exchange documents with your trading and supply partners, data ingestion, AI agents. But the primary focus of today is going to be how we support API management. So really the ability for you to not only expose services, and we're going to talk a little bit about what some of these services could be or what some of these use cases could be, but also managing, those services, managing those APIs, to ensure that the data you're exposing from your internal systems is secure, especially when you're sharing it with the outside world, like different partners, customers, or even different lines of business within your own organization. So before we get into the demo, I wanna hone in a bit on the difference between integration or a flow related use case and API. So integration, I'm sure you're pretty familiar here, but it's system to system data transfer. So you're exchanging data between different systems. This could be a quote to cash process where you're connecting your CRM or to your ERP. It could be lead life cycle management where you're connecting your marketing automation platform to your CRM. It could be employee onboarding and offboarding where you're connecting your HRIS system to a bunch of different applications to provision apps for new hires. But it's triggered by specific events or schedules. The data is flowing between those systems, and it's not being exposed anywhere externally. The difference with an API and it's asynchronous. With an API related use case, this is a synchronous real time response where you're actually taking data that resides in a system or it could be data across a process like a customer three sixty process. You're exposing that data as an endpoint to external parties. So that could be lines of business, could be partners, could be customers, and they're able to make a call to that endpoint and get access to data in real time. So it can be called from external systems, applications, or services. Now what are a few examples of API related use cases? So could be exposing a custom API to customers so they can retrieve order history, invoice data, or real time shipping tracking information from NetSuite or another ERP. Again, this is an internal system. You're exposing data from that internal system to an external party like your customers. Could be exposing pricing, inventory availability of product catalogs to distributors or retail partners. This is important, you know, depending on your business model, but we've had folks who who come in and want to offer a white label version of their product to different third parties. So to to resell a product, those third parties need access to your pricing, your inventory availability, and your product catalog so they can effectively resell your solution, and they need that data in real time. So that's another critical use case we've seen, more of a a data as a service. And then my picking system needs to get a real time inventory information from my ERP to ensure a full order can be shipped. So a bit similar there. And so what we want you to think about is once you're building all of these APIs so let's say you build a service to expose or an API to expose pricing, a different a b API to expose inventory availability, product catalog API. You need to make sure that these APIs are managed correctly. So there's a bunch of different things that you should be thinking about. One is security and compliance. So this is data protected. Right? You're exposing internal information from your back end systems, and you wanna make sure that it is secure. Scalability and performance. Are you able to handle traffic spikes? Do you have maybe things like rate limiting in place? Life cycle management. So how do you handle different versions of this API from when it's built to ultimately deprecation? And then monitoring and analytics. You want visibility into usage and performance of these APIs, through a single pane of glass. That way it's easy to tell what response times looks like look like, what utilization rates look like so you can alter your strategy accordingly. Another key piece is consumption. So exposing APIs through developer portal so they can easily be consumed by developers, whether they're internal or external. They can see documentation. They can submit feedback. This makes it really easy for them to understand what APIs are out there and how to interact with them. Otherwise, you can build the greatest APIs in the world and no one would ever discover them, which is a problem. So this is the life cycle that we're talking about. On the previous tech spotlight, we've spoken about how you can go about building an API and API builder, and we will touch on that lightly today. But the main phases of the life cycle that we're we'll be demoing are security, socialization, and monitoring. And Celigo provides full life cycle management all in one unified experience. And where we hope this this leads to for you is, where you can adopt a modern API led approach to integration. So imagine, a universe where you can take your core systems, core applications, your ERPs, your CRMs, your databases, and expose those services as an API so they can readily be consumed by the rest of the organization. And then also build out processes, so receipt status process that involves multiple systems, invoice status process, inventory, and pricing, could be single view of a customer. Such that you've created these building blocks, they can be reused on different projects or different initiatives. So maybe you initially have, as you can see on the top, the the API consumer, you have a mobile app. And then later on, you you build out a web app. Maybe you can reuse your inventory and pricing API or your receipt status API. That way you don't need to start from scratch on every new project or initiative. So there's plenty of ways that we try and facilitate the reuse of APIs throughout your organization. That way you can accelerate your speed to market on new projects and new programs. But as you can see here, by just the API build, your feature coverage that you see in the bottom left leaves a little bit to be desired. You don't have security. You don't have the ability to socialize these APIs. You don't have the ability to monitor them. So where API management comes into your modern API led strategy, as you can see in the top left, there's a portal you could readily discover, subscribe, and monitor, or socialize APIs. There's a gateway on top, so that's where security and governance is going to be enforced. And then there's the API and console that you see here, which is gonna help you monitor your APIs during production. So with API management, you have full feature coverage to roll out a modern API led approach to integration. Without further ado, I think Jean is hopping on now to the stage, and he is going to walk through a demo of the solution. Absolutely. I'm just gonna go ahead and share my screen here. Okay. I think everything is all set up. Alright. So what we're gonna do is we're gonna go through, a little bit of a review from the last webinar we did, on on how to build APIs in the platform. We'll quickly go through, some reminders or for those that weren't on last time. We'll and then we'll we'll then move on to how we expose, those APIs securely at scale using, our API management functionality. So first, take a look at, take a look at integrator here, and you can see that I have a number of, I have a number of of APIs defined in, you know, in here. I'm gonna take a look. I'm gonna take a quick look, at one of them, which is this ad product. And as I look at this ad product, the first thing the first thing we do, for any well defined API is establish what its inputs and outputs are. And so looking at that, you see that I have a a definition here so that I know exactly the data that I'm expecting to, to be here when this call is executed. Similarly, on the on the response side, I can choose, I can choose a schema to be able to define what that output is. And in the middle is everything you already know and love about Celigo. It's simple. Right? Everything is very you know, the simple, steps here where we simply take the data, we take the data from and do whatever it is we need to do, and then map it into and then map it into this response. So so this is really all that's needed, to create an API. Now, what you can do is you can go ahead and copy that invoke URL, and as long as you have the correct API token, to be able to call this, you'll be able to execute APIs directly in right, directly in Celigo. And that's great. It works well for either smaller use cases where you don't have to worry about, external entities or maybe, or maybe your security requirements aren't that, you know, aren't that robust. So this is a great way to do this. However, when you start to think about how do I expose this service that I built into, you know, into a larger audience, whether this is your customers, whether this is your partners, Right? You now have the ability to you now have you now have to expose all of these in a far more secure way, and manage all of that at scale. So moving to moving back in, you know, into here, you'll see that I have a number of you'll see that I have a number of APIs that I've already exposed through API management, and you can see that through the API embeddge right here. What I'm gonna do first is I'm going to I'm going to I'm going to demonstrate what it looks like when I say, okay. I'm now ready to move I'm now ready to to publish this into APIM. So when I do that, not this one, this one. Right? So here so here, all you have to do is click push to APIM. So when I do that, right, I have the ability to create a new API, or add this function to an existing API. So if I'm add if I'm creating a new one, I provide a context path, a method to execute, and the endpoint. If I'm adding to an existing one, you'll see that here are all of my here are all of the APIs that are already published. Once I do that, it it will then bring me into the API management console, which is right here. So there this screen is a little bit busy, but, at its core, you simply you you simply give it a name, and a description. You have the ability to add labels, to define what categories this API belongs to. We'll take a look at that a little bit further in a minute. And then at the bottom, we have all we have all kinds of life cycle, all kinds of life cycle options. So, obviously, the ability to start and stop the API, but then we come to then we come to this publish and unpublished portion. So one of the features, that we one of the features that we highlight when you're looking to socialize or make your APIs discoverable is, one of our features is to allow for a developer portal to be exposed by your team so that you will so that you will have a rich catalog of all of the services that you provide to your ex to your external audience. So being able to publish that API will say whether or not that will be exposed or or that will be published and documented in the developer form. Making the API private, this again relates to the portal. So if it is private, you actually have to have a credentials in the developer portal. Otherwise, it will appear, in the Apollo pages. And then, of course, deprecation and deleting the APIs. Now the primary you're right. One of the primary reasons, you would use APIM is to is to secure the API at scale. And the first step in doing that is to create a plan. So looking at the plan here, you can see I have a single, I have a single published API plan. This one happens to be a key plan. However, I can add these new plans and you can see that I have a a list of authentication mechanisms that I can support here including OAuth two JWT, API key and a public or keyless plan. Now selecting the authentication mechanism is just the first step. There are a number of there are a number of ways to create different plans to support not only different different authorization types, but also, but also being able to restrict, what a particular member of a plan can do. For instance, if you are looking to provide, say, say additional functionality, let's say rate limiting, things like that, you might want to have a silver, gold, and platinum tier, each with different rate limits, that is what you would use a plan for. Each plan would have its own, its own set of rate limits. So if I go in here and pretend to create this, if I go through and look at all the options available to me in that plan, you'll see that I can control per plan, rate limiting, the amount of, you know, the quotas, and resource filtering. Now when it comes to resource filtering, you can you can use some very interesting things. So for instance, you can have a plan, right, you can have a plan that will simply that will simply only allow gas. Right? And what you're effectively doing here is you're effectively making a read only plan. So you can have a user so you can have a full API, to do both reads and writes, but we can restrict who can actually write to it simply by simply by selecting the appropriate plan for that user. So the this is just part of that powerful, part of the powerful functionality here. Also, you don't have to plan for any of these restrictions as you're building the API. All of that functionality is taken care of in a configuration, in a in a in this configuration here right at the API gateway level. So if so, again, going back into the plans, right, so this is the major way how we how we secure, how we secure and authorize who gets access to what. Before I move on, I'm going to move over into our developer portal. So our developer portal, again, is meant for people that want to consume our services. So in this case, this would be one of your customers or partners or some other entity. And you can see here I have a number of categories and I can choose, say, a customer service. And here is my order master, API. Now I can go ahead and view my API and you can see my front page here. I have some very business level context here to define, exactly what this API is, what it, you know, what it does, what it's intended to do, right, who the who the particular audience is. So you can go through and create very detailed documentation here. I'll show you how in just a few minutes. But more importantly, if I am a developer, I'll take a look at this and maybe say, okay. This makes sense. This is what I want to use. Now how do I actually execute this? Well, for there, you can go into the documentation feature. And in the documentation feature, you'll notice you'll notice that we have a full set of technical specifications for the for this API. So if I go ahead and look at my add products here, you'll see this is the, right, this is the input schema that it's expecting, and this is the output schema that I'm expecting. So I'll be able to so I'll know exactly what I need to do to actually exit this API. So I now look at the I now look at the API spec. I see that this supports what I need to do. As a developer, I can hit subscribe. That will start the process of of applying to for a subscription to this particular API. Now the the publisher of the API, has the ability to say, I'm going to either automatically allow, anybody that applies for this subscription, to immediately get one. And in which case, because I'm on an API key plan here, it will just give me the API key, and then I can use that in my application, to start making requests. However, you also have the ability to you also have the ability to say, no. I want to manually approve, each and every each and every request. So in that case, that provides a a number of pieces of functionality, not just an automated not just a sorry, a manual approval process, but there's also an entire set of back end APIs for our API management console. So if you wanted to if you wanted to do something like validate, whether or not this person's plan with you has been paid up in full before granting access, that's something that can be handled, programmatically, with either a Celigo flow or something else that will validate it before automatically approving it after validation. All of those things are possible using our back end APIs. Now going back into the API management console, right, one of the one of the features here is the documentation feature. This is what gets published in the portal that I just showed you. So if I look at my home page, you'll notice the home page is in markdown mode. I have the ability to edit this with markdown, or simply go into a WYSIWYG type of, a format here. I have lots of options in here, but this is where this is where you this is where you define things, at a business level context to to make sure that your developers are, you know, are able to discern whether or not this API is the right one for them. Similarly, we have the technical specs that I showed you earlier, and those specs are automatically created, with the open API spec. And those are gen that open API spec is generated for you automatically when you push a Celigo API into APIM. So you don't need to touch this. It's always up to date, and so we will and so all you have to do if you wanted to view it, right, so on the left hand side here, this is the actual open API spec document. And on the right hand side is the visual version of it, that you probably recognize from just a little while ago. So you have the ability to do all this. There's also, there's also some there's also some things in here to be able to, to be able to do things like, do I want this to do I wanna show this in swagger or redoc, for those for those that care? But even more importantly is in allowing an, a try it mode where you can, where you can expose the ability for somebody to enter their credential in and be able to try this right from that documentation page. This is a great feature for developers who wanna understand a little bit more about how it's used before actually subscribing to it. So with that, there are so with that, there are a number of other features in here. I'm just gonna point out a few for now. So first, first for if you are planning on allowing this service to be exposed, via a web application, let's say, you'll want the ability to enter in CORS information. CORS is a cross up cross up origin resource sharing, which is just really a fancy way of saying, I'm not going to allow, a a web app to access another web app without explicitly saying that that app is allowed to communicate with me. So you have all the information and all the available all the available configuration options, right in here. Second, we have a good deal of analytics here. And while I haven't run this in a while, clearly, but, I have a tremendous amount of logging information that I can, I can show here? And I just wanna show you because, I just wanna show you what that looks like, because number one, took me a minute to figure it out. But it's very intuitive once you once you look at it. So when you're coming in here and showing, right, and being able to to experiment here, you'll understand what you're talking about. So as I'm go as I go through here, and I'll take I'll take just this, I'll take this this request. And, right, what this is doing is I haven't really turned this on yet. But what this is doing is it's allowing you it's allowing you to see the request coming from, the consumer of the API, at the on the top left piece here. Then on the top right, is the in is the information is the information about the communication between the gateway and the back end service. In this case, we're talking about a Celigo API. On the bottom right is the response from that Celigo API. And then on the and then on the bottom left is the response after it goes through the API gateway. So you have so you know exactly what was modified when and what and what exactly that looks like. So, that is, that is pretty much what I wanted to show today from the from our API management piece. So so I wanted to talk a little bit more about what would right. So best practices that when you're creating, APIs, and it really comes down to focusing on the development experience. Right? What you wanna make sure you're doing regardless of what you regardless of what standard you choose to select. Right? Just make sure you're consistent. I'll talk a little bit more about that, a little a little bit further down the line here. But enforcing robust security, make sure that the authentication options that you're selecting make sense for your appropriate audience. Use plans, as I showed you, to manage that access control and, and and be able to apply the limits, that those plans allow you to have. Right, your cut you're using using your portal, right, is being able to expose let's say you're exposing a a fairly large set of services. Right, having that developer portal saves, you know, saves the consumer from constantly having to bug the API publisher on, I don't know how to use this, how does this work, I'm getting problems. Right. So that portal allows for a lot of great a lot of great documentation. A feature I didn't show, in that developer portal, but is important is the ability to log tickets so that you can have a communication between your publisher and your developer. So, you know and then just other things to think about, when we're talking about APIs is using your version strategically. This is one of those this is one of those things where if you don't do it right, it will, right, it it can cause issues down the line. Right. So and we support, we support API M versioning, out of the box to make sure it is done the right way. Right? So what you wanna do is whenever you're whenever you're updating your back ends your back end service to something that is, potentially a breaking change, you're probably gonna update that version. So, say v one, v two, whatever it is, and that that version indicator, should be part of your URI. That way that way somebody is not making a mistake of thinking they're using a different version of your service. So so we handle that out of the box. We kind of we've we've built that with intention, to protect people from, well, themselves, to make sure that we are to make sure that that those types of issues are not happening. And then finally finally, we you do, like, this can developing these these API services, can give you different areas to expose your business to, in ways that might even you know, you might not even be able to monetize. And so and so we can support, API usage, and, you know, and all of that going to a monetization platform. Happy to talk more about that if you're interested there. But that is you know, but these are all things that these are all things that you can do, using our API management platform. So to wrap up, right, the idea is when you're using API management, right, the two most the two most critical pieces about when you should be using API management is when you're exposing it to several external audiences, or internal if you're a if you're a larger organization. And then if you're handling and then if you need to do any kind of rate limiting, quota limiting, things like that, to be able to protect that back end service, that is something that it supports as well. The ability to socialize and and publish this to a developer portal, makes, makes not only the lives of the consumers of this API better. It also makes the life of the publisher better because you don't have to answer as many questions. And when you do have to, there's a very organized and structured way to do it. And then finally, the ability to monitor, analyze, grab log files, and do all that to be able to assess, the health of your service, is really the is really the most critical part of maintaining any of these applications. And with that, I believe, I believe, Chris, do we wanna go through do we wanna go through the rest of the slides and then answer questions? Yeah. Let's do that. Okay. Well, I have to reshare. Sweet. So just to wrap things up, this is kind of a brief synopsis of really the scale that's legal has been able to operate at over 40,000,000,000 records process each month, hundreds of millions of error solved. So really just the ability to solve all of your problems, not just in one off use cases, but at scale and for leading companies that you see on the right. We're the number one iPaaS on g two. I believe it's six consecutive quarters in a row now. We need to update the slide. And another awesome development is we're actually named as a leader in the API management quadrant on g two as well, for the first time two months ago. So super proud of that. Again, g two is ultimately the voice of our customer, and all of their ratings and rankings are based on customer feedback and reviews. So it's awesome to to hear that from our own user base. Just a few sort of upcoming events to be aware of. First, our our physical in person events. So our connected roadshow we have in Atlanta coming up on November 5. It's been an awesome experience so far, and I would say it's really a way for prospects as well as current customers to discover the full capabilities of our platform. So we don't just go over some of our core integration use cases. We also go over things like what we talked about today, API management. We talk about our EDI offering. We talk about new AI use cases. So really gives you a sense for the art of the possible when it comes to the Celigo platform, and you can get a sense for our future roadmap as well and meet with our product team. So highly recommend that you attend. The link to sign up is below. Soligo.com/soligoconnectiveroadshow. We'd love to see you there in Atlanta. Again, that's coming up November 5. We also have a few more tech spotlights coming up on also November 5 and December 2. So, again, similar to today, we would go through sort of an in-depth technical breakdown of part of our product. So recommend that you you sign up for the whole series and get as deep as you can within our offering. And then on the docs side, you should be able to see a few blog posts, so a breakdown of the secure, socialize, and monitor page. If you don't, definitely ping us in the chat, but it should be in the doc section so you can get a deeper reading. And, yeah, we already mentioned the roadshow. So at this point, we will move to our q and a. I think there's some in the chat right now, but feel free to drop any in the q and a, and we will get to it. Let's see. So what's the process for registering an existing integrator, the IO built API in API management? So I think I can take that one if I'm understanding that question correctly. So you're just asking how you can move or push an API built within Innovator IO either through API builder or through JavaScript or imports and exports to API management. So you'll actually see in the the resources tab after you built an API, there's three dots. You can click those dots, and it'll give you the option to push to API management. And then once it's already pushed to API management, you can you have the option to view it in API management. So API management will import the the name of the API, as well as the the OAS spec automatically, and then you can make tweaks to it as needed, once you get into the API management console. And I see that Jean already answered some of these in the chat, but Oh, no. I won't take the credit. That's all cost of. Oh, that was cost of. He's he's a few steps ahead. But, just to read it out to everyone, how does Celigo's API management layer handle different authentication methods or mechanisms? He said yes. And mTLS and basic auth as well. I don't know if that question was more like do you offer I think we showed right. So we showed so I I did show so all of those authentication mechanisms are supported, via the plans. Right? So the first thing you select when you create a new plan is the authentication mechanism. There are also, many other advanced features, that we didn't get into today, that allow you to have handle other authentication mechanisms as well, including, as Kosta pointed out, MTLS and simple basic auth as well, as well as many of the things. It's an extremely flexible platform, but we can support we can support a number of other options as well. Okay. So there's the if I'm looking at all the other unanswered questions, what's the process for registering an existing Integrator IO built API on an API and API manager? I believe I showed that as well. Right? Three arrow three dots and you simply click click push to APIM. And then the only other thing you have you absolutely have to do after that is, actually start up that start up and publish that API. And then it is up and running. Looking at some other unanswered ones. Are the recommended best practices for exposing integrator IO flows as APIs in enterprise environments? Okay. Not sure precisely how to answer that one. Right? Because a flow, right, a flow doesn't have predetermined inputs and outputs. Right? And that's really what separates our traditional flows from our API flows. And so and so and so being able to do that, you know, may be a little interesting. I can provide some insight though if you're looking at, if you're looking at potential of invoking a traditional flow, with from within an API call, if that flow is already set up to run on a webhook, you can send whatever data you want to that webhook to initiate that traditional flow. This is and and this is this highlights a lot of the composability, that we talk about here. One of the thing that I haven't actually gotten to today, but I highly recommend all of you take a look at it because it's pretty neat, is we have a new version of the Integrator IO connector itself. I believe it's called I believe it looks like Celigo API's connector or something along those lines. It's a little deceiving, in the naming, but it allows you to it allows you to call, all the things and more that the original integrator connector does, but also allows you, in simple drop downs to select any API to execute from a regular flow, and any webhook, that you may have set up, on a flow. Those will all be available in that drop down as well. Highly recommend you take a look at that. That will that will start you on your journey to building these composable services, you know, that which maybe might be another topic for, another webinar, at some point. Okay. So, are there any recommended best practices for exposing integrated flows as API? Alright. So the other thing I wanted to go into on that one, right, is you know, and I think the the keyword I'm I'm harping on here is enterprise environments. Right? So, you know, so integrator, you know, integrator itself, if you're exposing APIs, through integrator for your internal teams, I think that's great. It works well. It is, you know, it is secure, but of course there are more secure mechanisms than simple API keys. But and that's where and that's why I recommend, for enterprise environments, you should really focus on the authentication mechanism to make sure it's as locked down as possible. So my number one thing, how are we how are you going to make them enterprise ready? Expose them through API management. And then finally, what type of support is available if something goes wrong with APIs? Well, that goes through our normal support channels. You know, you know, we have, you know, incident response, around the globe twenty four seven, depending on your service plan. Let's see. Anything else I'm missing here? Anything I missed, Chris? No. I think maybe that question was talking about or the support question was referring to, like, something going wrong with the APIs, like, the API erroring out. Sure. So, you know, if the right. And I I think the the support answer is still the right answer. They're gonna they're the ones that are gonna be there, when it falls over at three in the morning. Right? So so those are the ones that right. So those support is really your first line of defense there. However, you do have the ability, within APIM, to turn on debug, and, you know, turn on those debug logs and see the messages coming through to help you pinpoint exactly where that's going. To take that another step further, I'll just highlight, you know, one of our upcoming enhancements. Coming up is, our enhanced logging, that we're gonna be rolling out throughout the entire integrator platform, that will allow you to see what's going on step by the the inputs and outputs of each thing step by step, a large enhancement, to where we are today. But those are, you know, but those are all techniques you can use to, you know, to debug your processes. Awesome. Thanks for that. I don't know if we have any other I just got I just got, I just got one more. Can we automate plan assignments or usage quotas via iPaaS flows or scripting? Short answer is yes. So if you were so if if you wanted to to use the back end APIs for our API console, you have the ability to do that where you can create a plan, against a particular API, and you can automatically enable that. That is literally how we are creating them when they we're creating that first plan. We're creating that all via the back end APIs. So, yes, all of that is absolutely possible. And, of course, plans are what determine your usage quotas. So you'd be able to define exactly what those are right there. Not seeing any other questions. Yeah. I think we're all set then. I'll give it another ten seconds. But if no one else has any other questions, we could go ahead and wrap up about ten minutes early. Let's see. Is there a new comment? No. Just a thank you. And, Henry, well, thank you all for joining. Really appreciate it, especially, again, everyone tuning in from, seems like, every continent today. So, thanks again. As always, you can feel free to, reach out to either of us at our email. It's just our firstname.lastname@Tulligo, and we're happy to follow-up and answer any of your questions. Absolutely. Alright. Thanks, everyone. Bye.