I'm having some trouble understanding exactly what is the issue in your situation, but if I'm reading you right, your issue is how to organize your development process locally, while still having the flexibility to test externally.
To this I say - don't.
If you are going to use an API gateway, test your part of the contract - what happens after the gateway. This way you can capture many issues that may remain hidden otherwise due to the API gateway and furthermore any attempt to test the gateway itself are exercises in futility - you are essentially testing an intermediate layer that has already undergone much rigorous testing than your process (hopefully, that is) and which is designed to hide/obfuscate the finer details of your own API.
Note: I'm in no way suggesting you shouldn't test the end result, too, but I believe your main testing effort should go to testing the code you own and maintain, not an external abstraction layer. Testing the external view is (IMO) for integration testing and for status monitoring (though this is more often than not provided by the API gateway provider).
As for how to setup and organize the process, I suggest using Amazon API Gateway or its competition (I've only worked with AWS, sorry). The very purpose of this service is to abstract away API-specific concerns, while letting you focus on the substance (it "lets you bring your value" in marketspeak) of the service.
Touching on the issue of redirecting requests to the 'local' development machine (note this isn't really in scope of this site, so I'm 'trespassing' somewhat, if you will), you can always use some VPN technology to connect the laptop to the API gateway. In terms of AWS, I believe VPC should allow this - take a look at this reference.
Finally, this question cries 'devops', which is why I'd like to take the time to point out that any such considerations are best discussed with the more 'sysadmin-y' colleagues, as their expertise will be essential in setting up something like this.