You're right. The definitions of boundaries between acceptance vs. integration tests is fluid and depends upon the team context. In our team, we define the ter

You're right. The definitions of boundaries between acceptance vs. integration tests is fluid and depends upon the team context. In our team, we define the terms less by tactics and more by intent. It's our belief that you can generalize your idea on what acceptance testing means. The intent of an acceptance test is to verify that -- no matter how it's exercised -- the implementation performs the work and outputs the result I expected. Now, you can exercise this implementation with any interface. Of which, a browser is just one interface to your application layer. An HTTP API is yet another interface; a command-line utility is another; etc. We actually have separate acceptance tests at the UI level and the API level. Sometimes even at the _feature_ level, in that it exercises a multi-step multi-result pathway through the application. The engineer responsible for developing a unit of work may or may not implement API level acceptance tests (it's recommended); the reviewing engineer usually writes an automated API level acceptance test that must pass for the merge request to pass from code review -> QA/QC; then the QA/QC engineer implements and runs UI level acceptance tests that must pass to move from QA/QC -> Done. We've found this process to be very effective in reducing our defect rate and improving the quality of our product.