At the moment Serenity/JS is initialised as a Protractor "framework", which puts Protractor in control of browser management. That's a good thing for UI-based tests, but not ideal for the REST-only ones.
I'm in a process of extracting the Serenity/JS core into a stand-alone module, which will support both #6 and #28 as well as your scenario out of the box. If you'd like to hack on it in the meantime though, then you could have a look at how serenity object is:
If you're running your integration tests with Mocha, it should be enough to create a mocha "reporter" that notifies Serenity/JS of test start/stop events and the test results. Probably something along those lines.
I will experiment a bit more, in the mean-time could I just create a second protractor.conf.js which doesn't include the browser type and capabilities etc. so it just won't spin up a new browser instance for my REST-API tests?
And then try to implement my journey design pattern to call a JS http request library as opposed to the BrowseTheWeb capability?
I would also prefer not to hack around with it as of yet I think it just creates additional problems in the future with the framework if you do new releases of Serenity-JS etc.