It isn't quite that simple but ultimately yes you'll need to open the incoming port for your IP address in your router configuration otherwise the request coming to the router will be blocked. Since you're using IIS and you're talking about an API I assume you're using the default 443 port for SSL. Opening that up should be fine.
What you need to consider though is that opening up that port means anyone can send a request to your IIS server for any sites on your server. If you end up hosting multiple sites then that could be problematic. What is generally recommended is that your site bindings only respond to a very specific DNS name (e.g. myserver.org) and this will at least ensure that you're only responding to specific DNS requests.
Another issue to consider though is that your IP address isn't static on the INet. Your ISP has only a limited range of IPs it can use. So when you connect to your ISP they give you an IP address. There is no guarantee you'll get the same IP each time. Even more complicated is the fact that your IP can actually change while you're connected. The general workaround for this is to request a static IP from your ISP but that costs more money. If you're going that route then you'll probably want to register a DNS name as well so callers can use your DNS name and not a static IP address that could change over time.
I wonder about your entire setup though. Are external callers actually calling you directly or are you calling external apps to get data. If you're setting up a system where callers can call you at any time then hosting this locally is probably not a good idea. You should consider hosting all this either on a hosting site or in the cloud. This will eliminate a lot of the security concerns, need for port forwarding, static IPs and even potentially DNS records as hosting providers handle this for you. The cloud is also an option if you don't want to go the hosting provider route.
Ultimately if you host a public facing server on your own network then you do put your network at risk if the server is compromised. You also have to manage the "always on" needs of the application, network usage (since an app could call you 100s of times a second), backups, etc. If you pay for bandwidth by usage then having external calls to you could eat that up rather quickly. As a test this might be doable but I wouldn't do this as a permanent solution.