I came across the new Desktop Underwriter (DU) API from Fannie Mae which provides lenders a comprehensive credit risk assessment data that determines whether a loan meets Fannie Mae’s eligibility requirements. They have a slick new website for the project, with the tag line “building on certainty”, and a smooth HTML story to walk you through what the new DU API can do. While the API seems very exciting, and valuable, the whole production is missing one thing–the API!
I am sure you have to be a partner to get access to the API, but you can tell the whole things is being led by people who have never actually used an API. Otherwise you would give us an API to actually use, and allow us to kick the tires. A hallmark of modern APIs is that you get to play with it. Marketing materials, and a sharp single page application website isn’t enough. We need the documentation, and be able to actually see what the request and response structure is, so that we can better understand the value being generated, and how we will be integrating with it. Without this, there isn’t any value. Of course, you don’t have to make the real API 100% public, you can always create API access tiers, and even deploy a sandboxed or virtualized version of the API and data for new users, protecting your valuable resources–just do not hide the API away from us, and make us consumers beg for access.
When you hide your APIs, you leave first impressions like you did with me. Wouldn’t it be better if my first impression was all about writing a story on how cool your API was, and how all my readers should be using it? Instead, I’m using you as a case of how to not do APIs. There is no reason the Fannie Mae Desktop Underwriter (DU) API can’t be publicly available, allowing us analysts and developers to read the documentation, and kick the tires. Another thing I want to push on back on, is the use of acronyms. I had to Google what DU meant. I know this is ironic, because of API and all, but I work overtime to spell out application programming interface (API) for my (new) users on a regular basis. Please don’t assume all your API consumers will immediately know what DU is. Please help unpack your acronyms, using a glossary, or expanding them inline as you explain what you do. It will make on-boarding much easier for the edges of your target audience.
Anyways, I look forward to some day testing driving the API (someday). I looked for a good five minutes for how to onboard with the API, and eventually gave up. Maybe someone involved in the project will read this, and email me with more information about how I could test drive, so that I can do a proper write up on what Fannie Mae is up to with aPIs. I’m happy to see such large entities working to make their valuable resources available via APIs, but I’m feeling like you might not have done all your homework on what API is, but luckily I’m here as the API Evangelist to help you understand the essence of why APIs work, beyond just the technology and acronym. I look forward to helping you along in your API journey Fannie Mae.
