Cross functional teams

Had similar but not exact situation.  The way we solved this was to start up Community of Practices(CoPs) across the "layers".  Our challenge were things like UX, middleware, and backend.  Our CoPs allowed the disciplines to continue to cooperate, establish best practices and maintain levels of consistency across all of the products. We have even had CoPs form around specific technologies such as Ember, Rails, etc.  Your API group sounds like a great example of how a CoP could benefit.  And there is also the chance that once the API group forms and finds benefit, other CoPs will form around other areas.  

they feel that the api team work better together as one, that the api should be viewed as a product in itself,

Is there any business evidence to support the contention that the API is a product?

and that right now they are losing communication flow and knowledge sharing and the work is too biased towards the clients

Perhaps the bias has shifted more towards the flow of value clients receive, and the work done — along with the flow of communication and knowledge — must now be revised to maximize value.

Thanks for the insights - i’d seen examples of something like a CoP elsewhere and I think it’s a good fit

In your experience could/should this group share a separate backlog of technical work that may be undertaken along with delivering a product increment? or is this work that should be captured in the product backlogs?

The work should be captured in the individual Product Backlogs if there is work to be done specifically for the product that provides value. And anything making it to the Product Backlog should be done with the Product Owner being involved so that it can be appropriately ordered.

If the CoP is more about standards and practices, there really isn't a need to incorporate that into the Product Backlogs. That type of thing would be better introduced as organizational practices or style guides. 

But, in my opinion, do not ever create a backlog that is not directly tied to a product. A Scrum Team should only work from a single backlog of items that are tied to a specific product. Again, from the Guide's section on the Product Backlog, here is the opening paragraph.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

If the technical work is something that must be done to individual products, or even a single product, it should be part of that product's backlog.