The ways in which endpoints interact and receive webhooks are like function calls with arguments and callbacks.
Documentation for programs is tricky, but often it makes sense to embed the documentation alongside the code (docstrings, comments, etc).
And where possible, it's nice for programs to be self-explanatory (minimizing the amount of documentation required in the first place). That can often require careful choice (and rectification) of variable, function, file and directory names and structure.
I'm not sure if that'll help much in practice - perhaps it's an unrealistic comparison to make between microservice architectures and programs. But maybe it'll provide a few ideas.
For other stuff we tend to just provide diagrams of servers/cloud services etc. Really the only way to understand it fully is to look at the code, but at least it's nice to have an entry point to the correct place. Unfortunately there are lots of non technical architects in my organization who tend to depend on documentation (which we have in confluence). It's not ideal really!