Feature Requests

I am working with the headless APIs to build a custom UI with the Documoto data backend. I have two main concerns. There are a lot of api calls needed for using this. In the example below I make a total of 54 API calls just to see get to one documoto page. 42 calls on the first page and 12 calls on the second page. (The second page is also a smaller example of the parts list for a page) Ideal State: I don't think the first page could be perfect but even if well could use our logic on the search API then the toc API contained the raw images it would reduce to 2 calls. The second page if the boms API contained the hot points and raw thumbnail files that would reduce that one to 2 calls. I have no way to retrieve thumbnails for Chapter in a book (media item). I am building two custom UI pages that are Fecon branded. The first one contains a serial number search that uses some custom login to find our "Parts Manual" that has that serial number tagged to it and display pages of the book (and chapters with pages in it). For this I have created a middleware API that retrieve all needed data from a few Documoto APIs listed below: I use search API to find the book with the word Parts in it. /api/ext/library/search/v1?q={serial} (Where serial is the search term from the pages text input box) I use the entityId of that book or media to get the Table of Contents to find pages and chapter to display name and page id. /api/ext/library/media/v1/{entityId}/tocs I use the id of each page to loop through and get the thumbnail image to show on page/shapter card. /api/ext/library/pages/v1/{pageId}/thumbnails I have to run this 1 time for each page After grabbing this data my middleware API return it a one clean json file as attached after passing in a search term. (BookPagesReturn.json) Clicking on a page takes me to a sub page to view the data contained in the page of the book. Here my middleware api is called to retrieve images and data for the specific page. I use the pageId to get the bom part number, qty, description and it's id for that page. /api/ext/library/pages/v1/{pageId}/boms I loop through each item in the bom to get the part images. /api/ext/library/parts/v1/{partId}/thumbnails I call the hot points API to get the hot points for that page by it's id. /api/ext/library/pages/v1/{pageId}/hotpoints I call the illustration to get the image for the page. /api/ext/library/pages/v1/{pageId}/page-illustrations After grabbing this data my middleware API return it a one clean json file as attached after passing in a pageId. (PageDataReturn.json)

As of now, Part Numbers can only be hidden globally. There should be a way to share a parts list with customers without displaying the part numbers. Some companies are not permitted to share complete parts breakdowns because the information is not their property. Ideally, the customer would only see the illustration, item description, and quantity. They could then select the items they need, add them to a cart, and submit a quote request to us without seeing the associated part numbers.

Icon special color? I'm really struggling to figure how to make this stand out more. Users have a hard time seeing there's a reason to click on a part and go to the Part Information Page. What can we do to inform them it's worth their time to view the Part Information Page?

While we have several options at how Search Results are listed, it would be nice to have the ability to 'override' all of that and list something else first, and then list the Search Results as previously determined.

Adding the ability to dynamically highlight BOM cells based on tag values would greatly improve interface clarity and user efficiency. This feature would allow users to quickly identify important statuses (or other information) by customizing cell background colors according to specific tag data. See attached.

Currently, when a user enters a search term in the TOC search bar, the suggested search panel remains in view (blocking the actual search results) until the user clicks outside of the search bar or hits enter or return on a keyboard. I would expect the suggested search panel to also close after the user has stopped typing for a few seconds.

Small item, but the search box needs to stand out a bit more and the text inside in so hard to read.

Once a user opens a PDF, they can select "Fit to Width" but most don't know about the button nor have time to click it. We should be able to set it within the media so it just automatically provides the best view for the user.

I'd like to propose a new tag input type that sits between the existing LISTBOX and TEXTFIELD structures. I'm calling it a "Prefixed Text" tag for now, but I'm open to whatever terminology makes sense. THE CONCEPT This tag type would combine two inputs that resolve into a single stored value: Input 1 - A configurable dropdown (the prefix): an administrator-defined list of categories, names, or identifiers. Input 2 - A free text field: where the user enters the associated value. The two inputs would be stored together as a combined string. Example: Giant:12345 or Parker:67890 WHY THIS IS NEEDED I am building a structured tag schema in Documoto to support part data standardization and downstream reporting in Power BI. One use case is tracking manufacturer and vendor part numbers, where a single part can have relationships with multiple manufacturers each with their own part number. The existing tag types don't solve this cleanly: LISTBOX alone cannot capture the associated part number. TEXTFIELD alone introduces too much variation in how manufacturer names get entered, breaking reporting consistency. Creating a separate tag for every manufacturer is unscalable given the size of our vendor list. Since Documoto already supports multiple values on a single tag, a publisher could apply this tag multiple times — once per manufacturer — keeping data structured, consistent, and reportable. POTENTIAL USE CASES Vendor part numbers Certification bodies and their certification numbers Compatible equipment makes and their model numbers This would be a meaningful addition to the tag framework and would make Documoto significantly more capable for organizations managing complex part data at scale. Happy to discuss further or provide more context.

Currently, when an item is added to the shopping cart, that item turns red within the bill of materials. I would like for the color of the hotpoint in the illustration to also turn red. It would be nice to be able to control the color of both the item in the BOM and the hotpoint when the part is added to cart. This would make it more clear to the end user that the part has already been added to the cart.