Sharing code with API vendor for review without giving them access to the server or repo

Question

A private company allowed me to use their API to make REST API calls (using Basic Authentication) in my application's server side. They also asked to see my implementation before I can go live.

From their standpoint I understand they would like to make sure the API keys are secure enough.

From my standpoint I would prefer not to grant them access to my server side code or my GitHub repo, but rather, like they asked, just show them how it was implemented.

What's the "normal" way of doing this? How can I achieve this without coming off as rude?

We are communicating through email; is it out of line to just send over a .js file from my node.js server that shows them how it was implemented, without them seeing it live or having access to my server/repo?

I understand this question is similar to Hand over source code to customer and Freelancing - Share the source code? but they don't seem to answer my question.

Answer 1

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?

Update: 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.