In most situations this is a Bad Idea™.
It breaks encapsulation, but much worse it opens you up to supply chain risk.
That FileService API isn't guaranteed to function the sameway tomorrow. It might get a bug fix, a new bug, or suddenly sprout new (and possibly) breaking features. Eitherway its change that you won't see coming, and you won't be able to do anything to ameliorate that risk till its already happened. (Even if you a subscribbed to their release schedule/maintenance blog/or other change notification channel).
That being said if your specific circumstances are that:
- Service A and Service B are services within your own company.
- The FileService API can be accessed securely from Service A and Service B without exposing it to external clients.
- You have a system for tracking interfaces between your services that can describe this scenario.
- And you've done your due diligence to ensure that this does not bypass business logic.
Then its a reasonable decision to make. Its no different to providing file-drops via a shared-drive. There is some additional complexity in securing the interface, and in ensuring that partial files aren't mistakenly processed, but this is what mainframes having been doing for decades.
As for downsides it certainly makes the api more complicated, as Service A essentially exposes the FileService as part of its interface. That's not much of a downside if Service A is merely providing extra orthogonal functionality (its a strict superset of FileService), or if this is a literal file-drop making the FileService API a communication channel not an internal storage mechanism.