If you refer to Coverall’s API documentation, you’ll see that their Job API supports an optional parameter called service_number. Now by default this option is intended to match the build number for the CI system, but there’s no reason you couldn’t use it to track multiple coverage reports for each CI build.
One way you could do that would be to track the actual CI build number, multiply it by two, and have that number be the “backend” build number, and increment it by one to have it be the “frontend” build number. The doubling just ensures that you don’t end up posting to the same build number more than once. Of course, you can use another method for generating these IDs – the API technically takes a string so you might be able to submit e.g. 234-frontend and 234-backend.
In theory, you could also use the required service_name parameter to the same effect. The catch there is that some of the reserved service names (“travis-ci”, “travis-pro”, or “coveralls-ruby”) have special features, which you may be reluctant to sacrifice.