Ultimately it depends on whether you are 100% confident that the external provider will deliver something you can use by the time you need to use it.

If you cannot be sure that they'll deliver in time they don't add the story to the sprint. However, even if they've always delivered in the past there's no guarantee they'll deliver this time.

You should let the customer know that this dependency exists and that you are going to have to wait for the API (or whatever) to become available before you can schedule the work.

On the plus side, there may be aspects of the story you can deliver - i.e. break it down further until you've isolated the dependencies as much as possible. This might allow you do some of the story before the supplier delivers their work.

Ultimately it depends on whether you are 100% confident that the external provider will deliver something you can use by the time you need to use it.

If you cannot be sure that they'll deliver in time then don't add the story to the sprint. However, just because they've always delivered in the past there's no guarantee they'll deliver this time.

You should let the customer know that this dependency exists and that you are going to have to wait for the API (or whatever) to become available before you can schedule the work.

On the plus side, there may be aspects of the story you can deliver - i.e. break it down further until you've isolated the dependencies as much as possible. This might allow you do some of the story before the supplier delivers their work.

One thing you could do is to create an interface between your code and the third party API. You code to your interface so the rest of the project can proceed and until you have the real API use a mock to return example data. Then when the real API arrives you just have to change the code behind the interface which won't affect the rest of the application. Only do this if you can agree with the the API's supplier that their interface won't change (at least not drastically).