I deleted my first answer. I got carried away by your question "regarding the one connection from a single source". And started finding solutions for problems that did not exist....
Here is my more structured answer.
Usually you will see that the API client is sending a Connection: Keep-Alive HTTP header. When a request from a client to a server has Connection: Keep-Alive in its header, the server will not close the underlying TCP connection for a certain period of time even though the request from the client has been completed. When the client issues another request within that time period, the TCP stack will normally take the already open connection to the server and use it to transmit the request. So there is no waste of time (latency!) for the client when sending requests to the API.
If the client is not sending Connection: Keep-Alive (rare case), then each API transaction (GET, PATCH, DELETE) is one TCP session and will close at the end of the transaction.
However with LTM only you can try to rate limit with this iRule.
If you are using APM you can take a look at these two links:
They are ideal if you have another factor you could use for rate limiting? In case requests differ by maybe a certain HTTP Header (Authorization?) or some piece of unique information in the message body API request, you could use this information for rate limiting.
If you are using ASM you can configure TPS-based DoS protection by Source IP.
Thank you so much for your time. I will detail our scenario. We do not have APM. There is a resource intensive api which is expected to be called more in coming days. Hence in our VS, we created a policy that searches for this particular api string and forward to a new duplicate pool which has connection limit enabled.