Home
Who develops in the same API for both usage internal and external (OpenAPI) ? We have developed a catalog of nearly 900 APIs for the internal use of our various information systems and wish to develop open APIs accessible to third parties outside our organization. We are questioning whether we should develop our APIs in the same way for both internal and external use (OpenAPI), or if it is preferable to differentiate the APIs we develop with a separate design for internal and external use (mainly for security reasons and regarding the range of data we can expose inside vs outside our organization). Has anyone already faced this question?

Who develops in the same API for both usage internal and external (OpenAPI) ? We have developed a catalog of nearly 900 APIs for the internal use of our various information systems and wish to develop open APIs accessible to third parties outside our organization. We are questioning whether we should develop our APIs in the same way for both internal and external use (OpenAPI), or if it is preferable to differentiate the APIs we develop with a separate design for internal and external use (mainly for security reasons and regarding the range of data we can expose inside vs outside our organization). Has anyone already faced this question?

205 views2 Upvotes3 Comments

Sort By:

Oldest

Chief Technology Officer in Software13 days ago

We have exposed 200+ APIs externally to our users out of 300+ internal APIs. For internal service to service auth, we use auth based tokens and for external APIs, we refresh the token via another api every 3 hours and use that to restrict access the authorization for data.

VP of Engineering in Insurance (except health)11 days ago

We have faced this situation and have deployed some of our API's for external use. We created a hierarchy of API's - internal, system, experience and external. As you pointed out, external-facing API's have elevated security, performance, and documentation requirements.

Please join or sign in to view more content.

By joining the Peer Community, you'll get:

Peer Discussions and Polls
One-Minute Insights
Connect with like-minded individuals

CIO in Services (non-Government)11 days ago

We could say that if API security follows zero trust principle, the internal API could be open.
Unfortunately, our experiences is different. Most of internal APIs are not ready to expose them publically. The restrictions from security (WAF, token management, ACLs, throttling, audit, data sensitvity and confidentality) is different. Additionally, the exposed APIs will represent you and your company, it should be consistent, easy to adapt, atomic, well documented.
It does not mean that you have to redesign whole API, but mostly it requires at least another exposure on API GW and API wrapper. Within our clients (10s of companies in financial sector, manufacturing, telco and utility, where we either deployed APIM or where we maintain/support APIM or where we do enhancements developments) there is always external APIM a separated instance (or even different tech solution) from an internal APIM.