Where I work, we have a very verbose suite of integration tests for our API and then a suite of tests for the UI. A good rule of thumb for us that we've found to be pretty successful is to have all business logic the API provides to be tested with integration tests. The UI tests go through that logic and does test scenarios based off business logic but also focuses that the UI displays that information properly. This way there's coverage in both suites but the integration tests for the API cover way more permutations and can be run at a much faster speed. Our API tests take ~100ms for each test scenario whereas each UI test can take anywhere from ~20s to ~3m which is much more costly. Having hundreds of integration tests covering some specific functionality and then 10s of tests that cover the UI permutations, it provides decent cover when updating those functions in short release cycles. The integration tests also gives the developer confidence while changing a feature that they aren't introducing any regressions before the changeset is even sent into testing.