You know, Adam, it's interesting you say that: “to empower them to innovate.” And I think that our marketplace approach is kind of following a parallel concept as well. If you wanted to license the API, the new customer development, you're able to do that with the APIs we make available. If you want to leverage the power of APIs through a native integration, we make that available and we empower you through the CCH Marketplace.
One thing I would add to the support element is I think we follow a parallel approach when it comes to support. We have all these tools you mentioned, like the FAQs and developer portal, primarily to help support developers. But we also have a very robust professional client services or consulting services that are able to help consult with you and even develop integrations if you don't have the resources in -house. Also, we have a network of consultants that we work with at Wolters Kluwer that understand not just our APIs, but also the unique workflows in the tax and accounting profession. So if you wanted to tap into that network of consultants, we can help facilitate that as well.
I think just to underscore what you're talking about with empowering firms, there's different ways to do that. And I think the approach we take either with the Marketplace or firms licensing APIs or with self -service support or consultants is that there's a spectrum of options available for firms that like to really be empowered to realize the efficiency that APIs provide.
Data security and APIs
Adam, should we focus a little bit just on security and privacy, where you have a strong lens? How do we ensure the security and compliance of our APIs?
Great question. Okay, so we've implemented a robust security framework to protect our APIs as well as our developer portal. So all of the access of our APIs and developer portal, we call them, they're accessible via public endpoints. And those are secured with advanced measures, including protection against distributed denial of service attacks, as well as a web application firewall.
What is a DDoS attack, you might ask? Simply put, it's an attempt using a network of computers or “botnets,” to send a large volume of requests causing it to be overwhelmed and unable to handle legitimate requests. So we have protection against this type of attack. The other thing we have is API access requires user authentication.
And then all of the API calls that are made from a developer to one of our platforms, they're encrypted using industry standard protocols. And then there's additional application-level encryption techniques that are applied behind the scenes.
The other thing that's important is API access itself. In addition to authentication, it's controlled and limited with authorization policies. So, you could have a policy, for example, that enforces the ability to access only very specific types of data within our platform. The developer portal itself is only accessible to authenticated users as well.
The other important point to mention, especially for those technologists that are listening, we also have rate limiting that's in place. And what that does is that safeguards our applications as well as infrastructure. So that essentially limits the volume and the frequency of calls without it adversely affecting our infrastructure and other tenants per se or other neighbors that could be leveraging such calls and infrastructure.
Ultimately, this is just a little sneak peek. I don't want to go into too much detail because you have to obscure the security guidelines. But the reality is we have extremely comprehensive measures. And this is all in the spirit of ensuring confidentiality, integrity, and availability of our API ecosystem, as well as our apps and infrastructure.
API trends and tips for success
That's very reassuring to hear, Adam. Thanks for sharing that insight. I want to zoom out a bit. From your view as a technologist and leader in technology at Wolters Kluwer, what trends do you see in the API landscape and how are we preparing to addressthem?
I see a number of trends in the API landscape. The first one is GraphQL style calls. So what is GraphQL? GraphQL is more of a modern approach to building APIs that offers a more flexible and efficient way of retrieving data compared to traditional methods. So for example, it will allow a developer to request exactly the data they need in the structure they need, which reduces unnecessary data transfer and making it easier to work with the data. It's become very popular in the industry, especially in web and mobile application development, because it just ultimately it simplifies the amount of processing that is needed after the data is retrieved. And it also improves performance of apps.
The second trend I'm observing is more enabling ways to deal with real time or frequently changing data. So one that has really been increasing in prominence recently is an open source technology called Delta sharing. And what that really is, it's a way for organizations to share data securely and efficiently, especially for real time and frequently changing data. So what that means is instead of sharing entire data sets, it allows focusing on the sharing of only changes or updates to the data that reduces the amount of data that needs to be transferred, which in the end saves time and resources.
It's very useful in scenarios and we have these scenarios within our professional platforms in particular, where data needs to be kept in sync across both our platform and our firms' systems. And those are really the scenarios in which adoption has been prevalent or increasing in prevalence. And it's specifically in industry such as this one where timely data sharing is essential for making informed decisions and optimizing operations and applications. So those are really the two trends Shahbaz, a little bit techie, but it's really GraphQL and more Delta sharing for real time or frequently changing data.
I can imagine that's so valuable to our customers, especially in the time crunched environment we operate in some parts of the year. Just in closing, Adam, what advice would you give businesses? There's a lot of talk around APIs. We've talked about some of the approaches we have today in technologies. But if I'm a firm thinking about leveraging APIs, what should I do? Give me some practical advice on how do I approach leveraging this technology for automation in my practice.
So practical advice, and I think it's advice that we heed ourselves when we are developing new features or new products within Wolters Kluwer Tax and Accounting, starts with: follow a contextual design process that aligns on the jobs to be done. So in other words, what is the problem that you want to solve with APIs? But I think it's important to start with the problem, the problem statement.
Then determine the range of potential avenues for addressing the problem. That could be, for example, through a marketplace provider. It could be through internal developers. It could be through an external system integrator. You have to determine the range of avenues for addressing the problem. Then you have to engage the right teams to help. You should build, but build small. Phase it iteratively. So you want to build small, try it, measure the results, then continue to build and/or pivot. You have to take small bite -sized chunks, measure the results, continue to take another bite -sized chunk, continue to measure the results, and then keep that Agile cycle going before you get into management and support mode. So be Agile.
The only thing I can add to that, Adam, is if you want or need any help along the way, Wolters Kluwer is here to support you through our consulting teams, through our support teams, reach out to myself or even Adam for that matter.
