Name: Data-as-a-Service: Exploring Real-World API Use Cases
Uploaded: 2025-06-10T17:46:10.157Z
Duration: 31 min 19 s
Description: Data-as-a-Service: Exploring Real-World API Use Cases

Transcript for "Data-as-a-Service: Exploring Real-World API Use Cases": Oh, hey, everyone. Thanks for joining. We're gonna give it another thirty minutes to a minute for other people to join before we get started here. Okay. Awesome. Well, I'm excited to get started with you here today for our integration bytes series. The purpose of integration bytes for those of you, who this is your one is really to explore the art of the possible with our Celigo platform. So our goal is to showcase a number of different use cases to you so so you can understand different areas that maybe you weren't aware of that you can use our platform for. And one of the things we've done over the last few months and year is expand the number of integration capabilities that we support. And we've made a big investment on the API side, so allowing you to build and expose APIs from within our Celigo platform and interface. Today, we're going to be touching on a real world API use case with one of our newer products, API builder. So I hope you enjoy. As far as the agenda, we'll talk about more generally the IT landscape, the problem that this Celigo platform is solving, then we'll get a little bit more specific on the API side. So we'll go over some current challenges and examples of API based use cases. And finally, I'm gonna be going into the demo portion where we actually show you a real world composite API that we've created that actually does an inventory and pricing lookup. And, yeah, we'll end with it's not on here, but we'll end with a q and a. So if you do have any questions throughout the presentation, feel free to leave them in the chat. We'll make sure to get to them at the end. So the state of IT. Right? IT seems like they're constantly dealing with more and more, and they have a finite amount of resources. So it went from the role of keeping the lights on, so to speak, to now being the enabler of digital transformation initiatives throughout the an organization, and they're having to deal with more and more business demands. And then on the flip side, like I mentioned before, there's not that many more resources within IT. So they are tasked with a lot, especially on the integration front and API side, where they have to, not only focus on giving the lights on, but also work through new projects and innovation. And for integrations, that means building, maintaining integrations, and being on the hook for any maintenance or anything else that arises. So they're tasked with a lot. What we're doing with Soego is we're allowing IT to get to a a place where it's a federated model. Right? So where IT can give tile access to different lines of business. Those lines of business can automate the processes that they know best through a low code interface, and IT can implement the security and governance standards that they need to feel comfortable within an organization. So it really emphasizes this collaboration with the line of business and IT. Now how our platform has sort of evolved, and I touched on this on the slide. We now support all of these different integration patterns. So we started with application integration. Now we support b to b manager for EDI. API based strategies, including API management and analytics and data pipeline as well. So what this means is you can effectively train your team on one platform and use that existing skill set to deliver across whatever integration related challenges or patterns are thrown your way versus traversing all of these different tools, having to train teams on different skill sets, and increasing your total cost of ownership. Today, like I mentioned, we're going to be focused on API driven use cases. So I know the most common question we get, especially within our Celigo roadshows, which are our boots on the ground tours that we go to to connect with our users and prospects in various cities, is how do I know whether it's an API based use case or an integration flow based use case? What's the difference? How do I know when to build an API, when to build an integration? Well, here's a quick comparison. So integrations, you're ultimately delivering on an internal use case where you're connecting different systems in your tech stack together, and there's no external exposure. So this could be something like you want to automate your HR onboarding offboarding process. Right? Or you wanna automate your quote to cash process. That's a system to system data transfer. You're not exposing this data anywhere externally. Right? The data is flowing between the systems, and it's typically asynchronous. The API based use case, when you actually wanna take the data that resides in your core systems or core processes and expose that data to lines of business or could be for to customers or partners or even some sort of revenue generating opportunity. So when you think about your portals, your apps, those are all powered by API on the back end. Right? That's allowing these external systems to call it, and in turn, it's exposing the data that those applications need, to power a strong user experience. So it's synchronous real time response versus asynchronous, and you're exposing data outside of, a a lot of times outside of your organization, but at the very least outside of the those systems to other lines of business, customers, or partners. So what are a few examples? So here's what we've seen from some customers where we say, hey. You should really be looking into building an API for this use case. One, I need to expose a custom API for my part customers to retrieve their order history, invoice data, or real time shipping tracking from NetSuite or another ERP. This is actually interesting because this will be really similar to the use case that we'll cover in the demo later. We'll touch on that after. Next, are you exposed pricing, inventory availability of product catalogs to distributors or retail partners via secure API that's updated in real time from your back end systems? So in both of these cases, you are taking data that resides in NetSuite, ERP, Shopify, whatever your tech stack is, and you're exposing that data to some sort of customer or partner outside of your organization so they can call the API and get access to that data in real time. And this is improving the customer experience as well as opening up new revenue opportunities and decreasing the burden on your team. Right? So if you're manually exporting this data every week, you no longer have to do that. You can just create an API, put the right security in place, and kind of set it and forget it. What are some challenges that we see that really drove us to unveil a new API based offering? So one, we found that a lot of our customers had difficulty exposing data and services, from various systems. There was lack of built in security and access control for APIs, and there were slow and costly custom API development cycles. So we found that a lot of APIs were being, being built custom, by internal development teams that were already strapped. They if that those developers left, no one really knew what was going on under the hood of these APIs. They really couldn't be consumed in a lot of ways because they weren't discoverable, and they were traversing all of these different platforms. And we thought, how amazing would it be if the same platform you use to build integrations, you could also use to build APIs. So you could consolidate all your skill sets. You could use the same graphical interface that you know and love from building integrations and apply that to building APIs. So you could streamline your development, increase your efficiency, and then lower your total cost of ownership. And that's kind of what we did, and we came out with a new offering called API builder. So I'll mention this during the demo as well, but we've taken that biller paradigm that you're familiar with and then hopefully you like and are acclimated to that you see with the integration flow builder, and we've applied that to building APIs. So you're able to reuse a lot of what you've learned to accelerate your API development now. It's a similar graphical interface. Similarly, we have the new UI. And the the main difference is you'll see in addition to lookup orchestration and transformation steps, you'll see an API request node and an API response node at the end, and we'll touch on that in the demo. So what's the value prop? One, you're increasing your productivity. Right? This is a low code interface. Instead of having to write this custom, you're able to reuse a lot of our connectors, our logic when it comes to error handling. And then you're reducing your total cost of ownership because instead of using a separate tool to build APIs, separate tool to manage APIs, separate tool to build integrations, you're able to do that all in one platform. So we're going to get into the demo portion, and, really, this is a high level view of the different steps required to build an API where you can in through API builder, where you can find API builder, and I hope you enjoy. We'll be covering a use case that some of you might run into almost daily where we're actually going to be, working through how you can get inventory and pricing information that you would expose as a service to customers or partners. So when we're trying to find API builder, there's two main ways that you can access. So one is you hit this create button, and you'll see the option to build an API. If I quickly type this out, testing, you can see that there's a new API builder instance that's created. So this is an API request node and two error response nodes, and then I can add in all the steps in between. The other really easy place to find API builder is going through our resources panel. So we can hit resources, APIs, and I can see all of the existing APIs that have been created within my organization. You'll see API builder on the left and JavaScript on the right. JavaScript is the artist formerly known as my API. So here, if you're really technical, maybe you're a developer and you'd rather just write custom JavaScript, you have that option to build APIs through custom JS. And those are listed right here. For the purpose of this example, we're going to be covering API builder. So these are all the APIs that have been built, within this organization. We're going to be covering today, a use case with inventory management in Business Central and NetSuite. So I can click into that right here. As you can see, the paradigm is very similar to a normal flow. So the lookup steps are really similar. You'll have access to the same connectivity and orchestration and transformation capabilities. One of the major differences is actually this step. So this is an API request node. And click in here. we're going to name it. So we'll name this inventory and pricing API. Next, we're going to set the method. Right? We're going to be grabbing information from our ERPs, from two ERPs, and from Shopify. So our method is a get method. Finally, the query parameters that we're setting up, This is really what we want our end user to send us in order to execute on the API call. So we're going to require company ID and inventory source. What's really neat here is we have a preview tab, and you'll see this on most of our nodes slash connectors. We can actually test it out and edit the mock API requests and the dummy data that we're using for our testing purposes. So that's our API request node. Next, as you can see, we can use our transformation step to basically map, our data that's come coming in to data that makes sense to our downstream systems, ERP item ID, company ID, and inventory source, we'll have a boolean condition. So depending on where the record is going, it'll be routed to either Business Central and NetSuite. What's really cool about this API is we're combining data from multiple sources all in one API, and that's why we call it a composite API or a composite service. So depending on where the record inventory sources, if it's MSBC or it's NetSuite, it's going down one of these two paths. Let's check out the Microsoft Business Central path. We're running a get call, we're get a resource item, we're we're using the record company ID field to pass it in, and then you can see the the query parameters as well. Similarly, we'll be able to see a preview of what the parsed output would look like if we did make this call. And we have the ability to view our debug logs right here as well, similar to an integration flow. Now what we're doing is we're taking our inventory lookups from NetSuite or from Microsoft Business Central. We're using that data to look up the corresponding price in Shopify. So we're merging together and then we're looking up the price from Shopify. So we're getting the pricing information based on the resource endpoint and the Shopify ID, which we picked up earlier in the flow. Again, similarly, we're able to see a parsed output and preview. A really neat feature here is the success and error responses. So based on the success and error codes, we're able to come up with customized responses that we can send our end users. This is highly configurable and highly customizable. So as you can see here, if we get the default status code of that 200, we can create a custom response body or add the schema manual. You can select from all of these different status codes including I'm a teapot. So that is a real status code four eighteen for those of you who were not aware. And we can do the same thing for the error response as well. The default is the 500 internal server error, and we can add our our schema manually here as well, or we can choose a file that would go into the HTTP response body. So this is what the response would look like here. No data available, source is integrator, message at least one mock input record is required. Again, we could change this if we want. So as you can see, it's super easy through this graphical interface to create and compose APIs. A few other features that we can highlight here. One, we can run a test directly from this builder, and it would come up on the run console below. So we would have the steps, status, success, errors, pages, duration, and completed. We can also download our OAS spec. So our OAS or open API specification is a format that we can share with our developers or end users or customers or partners so they could easily consume the API and easily understand what's required to make a call to that API in a standardized format. Next, we can also view our audit log below. So as you can see, this is super helpful if you have multiple people who maybe have access to this API. You can see who made what change and when. Finally, another really important piece of the puzzle is security. So we get asked all the time, you know, what do you have for security when it comes to APIs? The short answer is a lot, but it comes in two basic layers. So we do have our API tokens within our IO platform. So This is out of the box. Right? You can create a new API token. You can name it security token for demo, And we can give this full access to everything that's been created, all the APIs, whether they were created through custom JS, API builder, etcetera, or we can do it by the API itself. So I could select that API that we just used, which was inventory management and Business Central and NetSuite, and this could be the token that's specific for that API. We can also set, how long the token lasts for, which is important as well, so the duration. Now we do have cases where people tell us, hey. I'm actually exposing data to a partner or a customer outside of my organization. So while the token's great, I wanna put things in place like rate limiting, or I wanna put things into place like a developer portal. I want enhanced analytics because I really want to understand the performance and how many times this API has been invoked over the last hour. For that, we won't be covering it here, but that will be part of our API management platform. So you can see here, if we go into our resources or APIs, I have an option to basically view this or push this into API management. So we'd be able to take everything that we've built, push it into API management, or we do additional security policies. We'd have the ability to socialize via portal, and we'd have advanced analytics and monitoring. So I hope this short demo, I'll stop sharing my screen now, was helpful in terms of getting acclimated with API builder, how it could work with a potential use case, basics on security, and then also a better understanding of how API management fits into the picture. Sorry again for those brief technical difficulties before, but hopefully, afterwards, you were able to see my screen and follow along. We do wanna save some time at the end for questions, and I see some that have already come in. So I will start answering those. If you have any questions or anything that's been on your mind, please do add it to the q and a. Okay. So question one, why would I build an API versus build a flow? So I did touch on this a little bit, and I can almost pull up this slide again. A flow is really app to app integration. Right? So you're moving data from one system to another, typically in an asynchronous matter. API or exposing an API is when you want someone to get access to that data that resides outside of the system layer. Right? So it could be a customer, partner, or other line of business. They're going to externally call that data, and they need it back in real time. Synchronous real time response, it's called by an external system. Then there's a time where you start to think about building an API versus building an integration flow. How does pricing work for API services? So API builder, which you saw through the demo, is a part of our integrator platform. It's available at the professional and enterprise level. API management, which I alluded to a little bit, it has things like advanced security policies, more analytics, and a developer portal to manage your APIs. That is an additional charge, and you can talk to your account manager or your AE, and they can cover pricing with you. Can you connect to any connector and expose it via API? Yeah. So the same library that you see within our integration flow library, you can also access via API builder. So you can do the same lookups that you could within our integrator flow. Let's see if there's any more questions. How does security work? So I mentioned that a little bit before, but we have an API token within our PIO platform that you can assign permissions either at the API level or at a broader level across all of your APIs. If you want more advanced security policies, we would recommend API management, and that has things like rate limiting, white listing IP addresses, things like that. If I'm using this Celigo flow that's triggered by a webhook, how does Celigo prevent duplicate flows from occurring in case the webhook fires off three times in a row. So I'm not a 100% sure on that use case. We'd have to have someone from our SC team take a deeper dive. I would think that to protect against the web of firing a bunch of times and that creating a bunch of flows, you would want to add some sort of logic to check if it had fired correctly. So some sort of logic earlier on in the flow seems like the answer to me, but, again, bring that up with your solutions consultant. They can get more into the weeds there. See if there's any more questions. We'll give it a few more minutes. And while we're waiting, I wanted to bring up our connected roadshow. It's almost a more in-depth version of what we do with our integration bytes. So we talk about the art of the possible, different products that are coming out in Celigo that you might not be aware of, like API builder, API management, b two b manager. We're going to different cities. So we've done New York City, Chicago, Salt Lake City, and we're showcasing all of this functionality, and it's an open discussion. So if you have any questions, if you wanna get hands on, that's really the place to be, and you can connect with our customers as well as other other prospects. So we have a bunch of sessions. We have a lunch, and then we have a happy hour at the end. We'd love for you to join us at the upcoming events. So we have Hyderabad, June 17, Dallas, August 20, Toronto, September 10, and Atlanta, November 5. I do see another question. Does this require a host key for it to be used in NetSuite? So I'm not a 100% sure on that question. Yeah. I'm not a 100% sure, what that question's asking specifically, whether it's saying to build an API that calls NetSuite, you would need a host key. Or if it's more on the integration side, you would need a key, or you would need access to get into NetSuite, whether it's an integration or an API. But I don't know if the question is that you need a separate host key for when it's an API. So, maybe feel free to follow-up with me after with a few more details. Kristafuraro@siligo.com, and I'd be happy to get back to you on that if I know a few more details. Does the standard bundle include API builder? It does not. So API builder is available in professional and enterprise. It's not currently included in our standard package. K. We'll give another thirty seconds, and then if there's no more questions, we can call it a day. I really appreciate everyone joining. You can also find, if you look in the doc section, more information, from on Builders Hub, so more information on API builder and Builders Hub, a link to our integration marketplace, which covers what we connect to currently or what we have out of the box when it comes to connectivity. Then you could also look into some more on demand webinars in the future. Okay. I do see a few more questions. Can a custom endpoint URL be defined for standard bundle customers? No. So you have standard customers do not have access to API builder, which is where you would define, things like the path. You would have access to expose an endpoint for imports and exports. So you can do that, if you'd wanna call an importer an export. And, that documentation is on our website. For somebody who is new to API, is there a resource to a very extent how to use the API build? Yes. There definitely is. I really recommend going into our documentation. So if you go to saligo.com/. Oh, let me confirm the documentation link, actually. So it's docs.siligo.com. Sorry. And you go to the main page. There's an option for build APIs, develop endpoints in the local builder or JavaScript. If you just click that build APIs button on our docs.siligo.com homepage, that will lead you to a number of resources that walk you through best practice in building an API builder. Awesome. So thanks everyone for joining. Really appreciate it. If you want additional resources, again, you can go to that doc section. And if you have any other questions or concerns, comments for me, we'd love to hear from you. You can reach out at chris.furraro@siligo.com. Thanks again.