Hi, OpenBoxes team. I'm a technical writer with a background in supply chain, and I want to contribute to your documentation because you're in that field and I can stand behind your product ethically. Fair warning: I have to yet to be hired, for pay, as a technical writer— I just have the "book learning" right now, and a few practice experiences. (here's my portfolio, and here's my last open-source contribution, for proof.)

I want to contribute to your API documentation to help me get my foot in the door for my first salaried job. So with that in mind, I've read a lot of best practices, API design, how they work, etc. docs over these past few months. I suggest the following changes to yours. (All up for debate; tell me if you think each is a good idea.)

1. The overview page I think needs to be merged with the getting started page. Maybe rename the "Generic API" title to "Using the Generic API".
2. It's generally best practice to have a "one-pager" because, at least from what I've read developers say, they like to use Ctrl+F to easily find what they're looking for instead of searching through multiple pages with different headings. This doesn't mean ONLY a one-pager— the other conceptual/task pages are important, too.
3. "Authentication and authorization" is a typical page for API docs— you currently have the info on a page that falls under a different header. I think it needs its own page.
4. Maybe a quick reference would be useful? example
5. Maybe a glossary would be useful? example
6. General proofreading of the Swagger API. There are some typographical errors.
7. I might be overstepping my authority here, but I think the very dark blue text that denotes a link is too hard to distinguish from the regular text. The links are not underlined, either, so it's hard to tell (absent context clues) what is a link in the text. If my contributions include links, I think it would be better to make them more visibly distinct than the regular text. I also think that your code samples on all pages would greatly benefit from being color-coded (I can easily set this in the mkdocs.yml). Maybe even change the code block background to black, with color text? When I scroll through the pages, the drab grayness makes the code harder to read and blurs together. But I'd also understand if you want to stick to your brand colors. Let me know what you think.
8. A few small things that don't impact much (for instance, a broken list on the core identifiers page).

I'll follow the procedure in your contributions guide. Just let me know your opinion(s) on these points. Thanks!