REST APIs are nice, right up to the point you need a transaction... three things need to happen in the correct order, and all succeed or are rolled back. If the API is too granular, then you end up pushing this logic to the client, and that turns into a disaster.
I'd personally rather go back and extract the smallest possible functional API, rather than build a massive API upfront. You don't really know where the transaction boundaries are as you are developing, and it is easy to expose an API that not really possible.
The way we handle this (we have 18 internal services) is that processes requiring transactions are formalized into a endpoint/resource. The actual transaction becomes tangible (e.g. you can cancel them by DELETE-ing on the resource) instead of just being documented. Only logic the client needs is the data to kick off the process. Async or long-running processes get a little tricker, but polling or webhook callbacks work fine for us.
A transaction should be the lowest level by definition e.g. it's not an API if you are just proxying CRUD on your db tables. Agree on smallest API possible (otherwise you will die in maintenance hell after you pick up a few clients) - but your API should be the only point of contact for your site and other clients.
I'd personally rather go back and extract the smallest possible functional API, rather than build a massive API upfront. You don't really know where the transaction boundaries are as you are developing, and it is easy to expose an API that not really possible.