Is there a case for parameterization using abstract classes rather than interfaces?

I am currently developing a component based API which is highly stateful. Top-level components implement about a dozen interfaces each.

In this way, the top-level components of the stock sit on the stack of abstract implementations, which in turn contain multiple mixin implementations and implement multiple mixin interfaces.

So far, so good (hopefully).

The problem is that the basic functionality is extremely difficult to implement (1000 lines of 5 base class layers) and therefore I don't want the component developers to implement the interfaces themselves, but extend my base classes (where all the boiler plate code is already written).

If the API therefore accepts interfaces, rather than abstract implementation references, which I want component developers to extend, then I run the risk of the developer failing the validation that is required and accepted by other areas of code.

So my question is, is it sometimes applicable to parameterize API methods using a reference to an abstract implementation rather than a reference to the interface (s) that it implements?

Do you have an example of a well-designed API that uses this technique, or am I trying to talk myself out of bad practice?