We are exposing OData APIs (which are essentially REST APIs). Is that a good approach or does it have any overhead?

There are significant overheads in terms of development, runtime performance and maintenance.

In general it is not a standard approach, but it is an option if performance is not an issue and you need some interface to aggregate multiple APIs and you really want to use the OData Protocol or a subset of its URL Query semantics.

OData over the top of simpler Web API or other REST endpoints is generally an anti-pattern. It will depend heavily on the backend API implementations and how you've mapped the OData routes and queries to them, but generally it is a lot of effort with diminishing returns, there are also significant SDLC overheads because this becomes a very non-standard implementation so you will need specialized and experienced support when/if there are issues.

I have recently worked on an OData Implementation that was mapped to a series of Repo DBs. The general performance and bandwidth arguments for adopting OData could not be realised because any wrapper over the top of another service can at best only be slightly slower than the slowest component in the chain. Overall the service was a lot slower and had considerable memory and caching issues to deal with the cross API relationship resolutions.

There are many non-performance arguments for OData that are in fact general arguments for Web API, security and caching are generally easier concepts to bolt into standard Web API that does not have the graph-like support for navigation properties.

One of the killer features of OData is the deep linking navigation support and the performance gains that can be realised by translating OData URL queries to linq expressions which can be deferred and executed by the storage engine. The general issue with non-OData APIs is that they are less likely to support IQueryable extensions and it is hard to translate the original intent in the URL in an efficient way to the target APIs.

An alternative is to design a staging or common data schema and use ETL processes to resolve the data from the disparate APIs into this centralised data store, then build an OData API to interact with this schema. This is effectively a cached OData service, rather than being a direct pass through to the external APIs but you can achieve some really impressive performance benefits from a solution like this.