User stories are a useful tool to think about solutions but there can be a tendency for them to become a golden hammer which has the potential to get in the way of delivery.
If the technical implementation is easily understood and has a self contained scope then a user story is likely to be sufficient.
However, this is where we need to watch we don't over-extend this logic by saying that the technical implementation should be recursively broken down into smaller units of scope until it they can all be described by user stories - this is the golden hammer approach. ("As a front end interface I need to request data from a back end API.", "As a back end API I need to provide data to a front end interface.")
Whilst trying to break down work into small self contained units definitely has significant value, the reality is that complex and interdependent technical work needs to be done and that's not best described by user stories.
The value of the user story is in it's name: it focuses thinking about the problem from a user perspective. We'll keep the user story around as the problem statement, and we'll check back against it if we're ever in doubt, but it's not driving the technical work.
The technical work will be mapped out and broken down and delivered in whatever manner makes most sense from an implementation point of view. Then, when the technical work has been completed, the user story will have been completed as a by-product.