OneTrust was founded in 2016 with the goal of making it easier for companies to operationalize trust and transparency. With over 14,000 customers across the globe, they’re growing quickly and needed an API documentation platform that could keep up.
Josue Negron, Senior Principal Product Solutions Architect in the Research & Development organization at OneTrust, was tasked with finding a vendor that could meet those needs and assist in his goal of improving their API documentation. Today, his role is something akin to a product manager for their developer experience, working closely with their technical writing team, along with product managers and developers.
As you can imagine, their API documentation gets a lot of use. Across those teams (and a few others), there are over 200 OneTrust employees who produce content in ReadMe, and they’re on track to have over 50,000 external customer developers by the end of 2024.
Switching from our previous vendor to ReadMe has been a night and day difference from a customer satisfaction standpoint; it’s a lot easier to navigate the documentation and find what you need. Josue Negron, Senior Principal Product Solutions Architect
In search of a scalable, secure solution
Part of what necessitated their migration to ReadMe was a change in licensing from their previous vendor. The new pricing model limited the number of admin users, which was completely incompatible with the number of internal users at OneTrust. With so many people across multiple teams working so closely together, limiting the number of users wasn’t an option.
In addition to a large number of internal users, they also needed their documentation platform to work with their identity providers. “We leverage two different identity providers — Salesforce for our customers, and we use Azure AD for internal users,” says Josue. “We needed to find a vendor that could integrate both of those workflows, SSO for the administrative workflow, and then SSO for our customer workflow.”
Despite his extensive search, Josue wasn’t able to find another vendor that could easily integrate with both of those workflows while keeping the identity providers separate, instead of forcing the OneTrust team to hack something together. Given the nature of their business, security is a high priority for the team, and being able to seamlessly integrate with identity providers frees up their time to focus on other aspects of their documentation.
A workflow that works for everyone
When looking for a new API documentation solution, there were multiple user archetypes and workflow needs to consider. The product architects and more technical employees rely on Jenkins automation and BitBucket, which works well with ReadMe’s command-line interface (CLI). This increases productivity and prevents them from having to learn a new toolset. At the same time, ReadMe's Suggested Edits feature allows for community-based feedback to be integrated into a CI/CD workflow built into ReadMe's interface, which gets reviewed, approved, and then merged by the technical writers.
Due to this combination of users, the OneTrust team needed to find a product that would allow technical writers and other team members with less technical backgrounds to use Markdown or a rich text editor with change management features and an easy-to-use visual interface. However, they also needed a tool that could easily integrate with their automation workflows. For example, when a developer issues a pull request and merges into a Bitbucket branch, they have a Jenkins pipeline set up that automatically pushes updates to the specification on the developer portal.
ReadMe was the best of both worlds, where it supported all the technical automations we wanted, supported all of our API standards and specifications, and was future-proofed. And then, on the technical writing and documentation side, it offers a rich text editor and allows for anyone to go and update documentation when needed. Josue Negron
APIs for all: Documentation for non-developers
OneTrust has a number of modules and product sets with different user personas, and that variety in users extends to their documentation. There are developers in their user base, but also plenty of people from other backgrounds as well! This includes (but not limited to!) cybersecurity professionals doing security research, data privacy officers, legal and compliance teams, digital marketing professionals, and risk analysts.
Their philosophy is to cater to all of these different groups and backgrounds by providing as many resources and as much information as possible, to make self-service as easy as possible.
I’d say only about 5% of our documentation users are actually IT people. The rest are all of these other types of people who can manage through some things, but aren’t going to be doing traffic analysis or turning on debug mode in their browser to troubleshoot. That means they really rely on our documentation. Roger Deane, Senior Director of Product Solution Architecture and Technical Writing
One example that Josue has run into repeatedly is that many OneTrust users rely on contractors to build out integrations, but often don’t give those contractors console access. “It’s just like, ‘here’s your client credentials, here’s the API developer portal, now go build this for us,’” says Josue. “That means they’re relying solely on our documentation to build their integrations, so if our documentation is incorrect or hard to use, the integration doesn’t work or the developer can’t find what they need to build it.”
Their main objective with the developer portal (and the documentation hosted there) is to create a hands-off experience that supports these diverse user groups in being able to troubleshoot and self-service on their own, without needing to seek outside help.
Their team tracks a variety of metrics to gauge how well they’re meeting this goal, including the number of 400 errors coming through, as well as being able to view what users are searching for in ReadMe. Josue notes, “If they’re searching for something like a webhook and we can see that it didn’t return any search results, we’ll notice that and create something that has that keyword and that will point the user in the right direction.”
Another feature that helps with this goal is Recipes, which caught Josue’s eye when he was evaluating solutions and is one of the team’s favorite features:
If I can invest a little bit of time to create an end-user workflow that a lot of our customers are leveraging, and even have that in multiple programming languages with instructions on the side where it highlights your code, that’s a very sexy feature for me personally. As a developer and an API integrator, it’s huge — it saves our customers a ton of time. Josue Negron
With a focus on creating an internal workflow that just works — regardless of who’s using it — combined with the goal of creating the best developer experience possible, the OneTrust team has used ReadMe to take their API documentation to the next level.
