First, building a Event Driven Architecture doesn't necessarily mean that your application interacts with the external world in an event driven way. Most of 3rd party services provide REST (HTTP) APIs that lead to synchronous communication patterns. Setting up some workaround that involves polling could help but there are two pitfalls I would consider
If I was a 3rd party provider I wouldn't be very happy that you call me every second. Decent API implementations have guards against this kind of usage (throttling, rate limiting)
You could resolve the previous point setting a long polling period, but this would make your fake-event-driven interaction useless because you cannot leverage its bigger benefit: timely status updates
So, the first step here is to check what interaction pattern your providers allow. Notice that "event driven API" doesn't necessarly mean that they will send you events through message queues, even webhooks could work well to bridge your event driven app with the outside
If there is no way to manage it, consider the idea to build an "anticorruption layer". some component can decide to fetch external data whenever a significant internal event occours, compare the outcome with the last recorded state and decide to advertise a state change in internal representation of the external resource.
In any case keep in mind that working with the outside in an event-driven way means to change the way your application performs distributed transaction, switching to the famous "Saga Pattern". I won't go deep on this because it's out of scope, but the basic idea there is that a distributed transaction can have a progress status. A component will keep that progress status up to date listening events and knows when and how to recover from partial failures