A third party that is going to make HTTP requests to the API that I'm building, requires that the API responds in less than one second. My question is, do they have a way (literally any way, within the bounds of the http and/or tcp/ip protocols) to abort the execution of my code if it takes longer than one second?
HTTP doesn't work like that. The client sends a request, then the server sends a response back. No other communication occurs. Well, the server can send 1xx informational responses before the main response. But there is no way for the client to send updates about a sent request.
(The situation is very different for HTTP/2 which can multiplex multiple requests over the same connection. A client can CANCEL a stream to indicate that it is no longer needed after it receives a PUSH_PROMISE from the server. I'll ignore HTTP/2 for the rest of this answer.)
Also, networks don't work like that. In particular, see the second fallacy of distributed computing: “latency is zero”. It is not. Of that one second timeout, 400ms may have been spent on establishing the connection and sending the request and 600ms on the response, because one of the packets was dropped and you had to resend everything and your client is in Australia. Aside from the problem that the server might not have enough time, the server doesn't even know how much time they have because response latency cannot be known in advance.
So given that literally implementing these timeouts is impossible, what kind of solution might be good enough?
If the response will have no value after the timeout, the client can simply close the connection. This will cause your response to be ignored, but will not prevent the response.
Closing the TCP connection over which the HTTP request is sent does notify the server. But this notification only arrives with latency, so it may be too late. Also, your web framework may not be doing anything when the client socket is closed. In that case you'd only get an error “connection reset by peer” once you try to write to the closed socket.
If you do not want to spend more than one second on processing for the response, implementing that timeout is entirely your responsibility, and has nothing to do with networking or HTTP.
You can ask the client to provide a timeout to the server, so that the server can abort if it cannot meet the deadline. This could be specified as a custom header, or as a query parameter in the URL. This deadline should be an absolute point in time and not a duration so that transmission delays also consume the available time. But sub-second accuracy is difficult: the server and the client need to be synchronized with the correct time and need to use a suitable clock. Depending on the setup each time source may be off by 100ms even when configured correctly. This already eats a significant chunk of your time budget.
I suppose they could close the connection, but I don't know if that would actually cause your code to abort - it would depend on how your code is written.
They could also send another message that could mean "you're taking too long so don't bother" but in that case, you'd probably already be prepared to handle an explicit CANCEL_REQUEST message.