# Establishing a Criteria for API 'Best in Class'
source: https://developer.mastercard.com/blog/establishing-a-criteria-for-api-best-in-class/index.md

Authors: Oran Cummins. After a number of years of leading Mastercard's API program, I often ask (and get asked) what constitutes 'best in class'. For me, I'm not sure there's a one-size-fits-all here as 'best in class' means an emphasis on different aspects of APIs depending on the nature of your business. For example, if you do business with a large number of smaller entities then '5-minute onboarding' or '6 lines of code' could be a key driver for adoption. However, if you mainly deal with larger customers - security, trust, reliability and operational fit are more likely to carry weight over rapid integration. Mastercard's API program today is skewed towards the latter (i.e. the larger guys, who then more directly power the smaller guys). We look at companies across many industries on their approach to APIs but when we land on a criteria for 'best in class', we do consider that in the context of what our customers care about most. Here's a number of factors to consider (in no particular order): Integration: Immediate access to a rich suite of tooling to make it as easy as possible for developers to self-sufficiently integrate and test in sandbox and promote to production. A popular measurement is 'time to 200' (i.e. the time it takes for a customer to achieve a first successful API call). We also like to measure 'time to prod' -- which is the time it takes from successful calls in sandbox to live traffic in production. Security: Striking the right balance between protecting all stakeholders on one side and rapid, easy enablement on the other. The security criteria is an area that 'weights' heavily for us. Mastercard applies significant rigor even on established protocols. Standards: Obviously the starting point is legal compliance across every jurisdiction you operate in. More thought is required when layering on adherence to the most respected API standards and adoption of industry standards where appropriate. For example, we've been working with Swagger/OpenAPIfor some time which (amongst many other things) helped us evolve our approach to SDKs Publishing: It's essential to internally adopt a highly streamlined process to publish and manage APIs. A key component here is the content management system where API owners can focus energy into content instead of grappling with tooling. We've moved from off-the-shelf offerings to a technology stack that treats documentation like code and supports different levels of authoring sophistication. Performance: We all strive for 100% uptime, low latency, low failure rate, but issues happen so having transparency on quality of service and giving plenty of notice on breaking changes. In summary -- although there are some common API criteria for best in class, it should be accepted that one size won't fit all. It's important to recognize what matters most to you, decide criteria weightings and apply investment accordingly. Undoubtedly that will evolve over time as market conditions change but it's a useful exercise to have clarity on what you're aiming for and where you're at on that journey.