adds more info to the versioning http apis dev docs for internal vs p…

…ublic routes

dev_docs/tutorials/versioning_http_apis.mdx

@@ -15,6 +15,17 @@ All Kibana HTTP API developers and maintainers must ensure that past versions of
   The exact number of past APIs and the length of time they are kept available will vary per use case. Generally, the length of time will be shorter for internal HTTP APIs than for public HTTP APIs.
 </DocCallOut>
 
+<DocAccordion buttonContent="FAQ: What is the difference between an internal and a public HTTP API?" color="warning">
+<DocCallOut >
+
+We only declare HTTP APIs that are stable and reliable as public and keep all development changes behind internal HTTP APIs. Public HTTP APIs are intended for external consumption and are typically garanteed not to change within a major. Internal HTTP APIs may change more frequently, as long as they adhere to the versioning principles outlined in the rest of this doc.
+
+**How do we prevent external consumers from using internal APIs?**
+Access to [internal APIs is restricted](https://github.com/elastic/kibana/pull/193792) behind a configuration setting, `server.restrictInternalApis`. When set to true (the default), external requests without a special internal header or query parameter are blocked.
+Of course there are ways of [getting around the restriction](https://github.com/elastic/kibana/pull/195696) but it has to be by choice and not incidental as it has been up to now.
+
+</DocCallOut></DocAccordion>
+
 Versioned HTTP APIs should hold to the following set of properties. **Note:** how you meet these is properties is up to you. Use the examples provided as a guide.
 
 ### 1. Do not directly expose persistence schemas on your HTTP API endpoints