You might write an API abstraction layer, to which your application makes calls for API communication, and through which all API communication takes place. Then you should only need to show the abstraction-layer code.
If that still feels sketchy, then write a proof of concept, "very alpha" version that does some basics, show it, get approval, possibly with the agreement that you won't extend the abstraction layer without resubmitting it (so make it comprehensive enough the first time). Then go on with your development, improving your application above the abstraction layer but maintain the layer's integrity (and thus, your own).
Because, surely, your hosts wont want to be bothered reviewing every new revision of your app, will they?
By "abstraction layer" I mean coding your own routines that communicate with their API. Both your proof-of-concept app and the app you go on to develop, will communicate only with your routines - the ones your hosts have approved. So they should really do more than replicate the API calls - they should present functional uses of the host's service at a slightly higher level, presenting useful host-service functions to your application. It would be ideal if your API-level error handling were in here, for instance. Then you host gets to see how you will use their API, without having to what you're using it for. Their concerns will probably be about how hard you bang on their servers, f/ex, and under what conditions, errors being a likely cases for concern. The more of your "plain" code you include, 1) the better they are likely to feel, and 2) the less follow-on work you'll have to do with regard to the service as you develop your application. You'll both win.