The term integration testing is a bit confusing as it is not always clear what the scope of the test is. I guess this article from Martin Fowler make a good distinction between narrow and broad integration tests:
https://martinfowler.com/bliki/IntegrationTest.html
With the narrow integration tests you could for instance test the interaction of code in several classes together. You can use the same test framework as that you use for the unit tests. The tests are written usually by the developers, you will at least need to have access to the source code. There is no requirement at all for having a public API for the application.
If you would have a broader integration test, (or in this case a very broad test) you could think of using tools like SOAP UI to test the Web Service of a full running application. This Web Service might be public or access is restricted to only interact with specific systems. If it has restricted access, then the environment must be configured to provide access for the SOAP UI tests.
Having publicly accessible API is thus not a technical requirement for being able to test at any level in the application. What probably matters more is what the relation between the tester and the development team is. If you need to test software developed by a third party, it is unlikely that you will be participating in creation of narrow integration tests. If you are working together with developers in one team then there is nothing that holds you back from doing so (other than your own coding skills).