Improving Integrations with Interactive Documentation

Did you ever try to integrate a 3rd party library? Perhaps a 3rd party REST API that you need to use?
Do you know that overwhelming feeling of exhaustion when you come across that HUGE amount of text which explains everything and feel like now is a great time to take a break?


Let’s try to understand why this has become so common.


In a lot of cases, SaaS products will have a Wiki-like documentation platform, in which a potential client will find all of the data they need in order to work with that product.


Having a lot of data in your docs is obviously important, however, when encountering a new product with new rules, inputs and outcomes, your clients will find themselves one on one with a lot of textual data.
In most cases, only part of this data is relevant for this specific client and it’s their responsibility to understand which part is relevant and which is not.


Sample of the vastly used wiki doc.



Look at the examples above, our clients used to have this experience, a fairly common experience for an API documentation.


This would mean they had to read about all of our parameters and then go and create their API request.
In our case, these types of integrations might to take up to a week, due to time differences and back and forth on email threads.


The solution that we found to be very helpful was to create an interactive parameter table, where each of them can be checked and at the end of the documentation, you’re able to generate your API call on the spot! (Please find what we’ve done).


Essentially what this would mean is that our client can now read the documentation while creating a final API tag for him to use.
In a single read, the client “walks out” with everything that he needs, which reduces integration time, back and forth emails and enable us to give our client the feeling that they’re working with a technical and sophisticated product.


As easy and trivial as that might sound, it does take some resources to build. A company will have to invest web development, design and marketing in order to get a very good experience. That being said, the gain we see and predict for future documentations is huge in many aspects.


Not only were we able to reduce integration time to be a matter of minutes (in some cases, our clients already built their API request on the introduction call that we had), documentation, in many cases are the first and last UI your clients will face and it’s a “once in a lifetime” opportunity to WOW them and make them trust and like your product before they even started to work with it.


Where can we take it from here

We’ve had a great experience with giving our clients an interactive experience when they come and learn our product.


We currently have this with our API documentations but are investing in creating a great interactive experience with all of our documentations as we could see how it affects how clients perceive us after using them and how much time and money we can save using them.

Matan SternSenior Technical Solutions Engineer

Read these next

Contact Us


Fyber N.V.

Office Address:
Wallstraße 9-13
10179 Berlin
Phone: +49 30-6098555-0
Fax: +49 30-6098555-35
Email: [email protected]

Managing Directors: Ziv Elul, Daniel Sztern, Yaron Zaltsman

Statutory seat: Amsterdam, The Netherlands,
Kamer van Koophandel KvK-Nr. 54747805
German Branch Office: Amtsgericht Charlottenburg, HRB 166541

VAT ID No.: DE289234185
LEI: 894500D5B6A8E1W0VL50

Editorial responsibility for content under § 55 II RStV: Eva Sayre, Wallstraße 9-13, 10179 Berlin


Fyber is not responsible for any content of third-party websites which can be accessed via links from Fyber’s website. Fyber does not control any of these sites and expressly dissociates itself from their content.


All rights reserved. Reproduction of any content on Fyber’s website as well as storage and usage of such content on optical or electronic data carriers only upon prior written consent of Fyber. Unwarranted utilization of such content in whole or in part by third parties is strictly prohibited.