You can do both. The important things are too
1. Choose the appropiate level of abstraction, so you can clearly describe the what and why of the behaviour without describing the how
2. When implementing the higher level scenarios just cover the fundamental behaviour (avoid exhaustive testing) and develop a strategy for setting up state.
When using external services with higher level services you have several options to set up state.
a) Write an `ideal` fake service which you use to drive the development of the higher level consumer (useful if the underlying services don't exist yet, or is under development, or is constantly changing)
b) Use the public api of a test implementation of the service to set up state
c) Use something like VCR to record responses from the service and use the cassettes to deliver state.
You can combine these techniques to meet your particular needs. Note that you don't need to reach inside the service to create state. You should just be using the public api that the service provides. If the service can't create state, then just record it with some state in it, and modify your Given's language to ask for that particular bit of data.
BDD is about describing behaviour. This can be done no matter HOW you are implementing the behaviour. How your software its architected is irrelevant to describing and driving the behaviour. If you are doing BDD correctly you are describing the behaviour BEFORE it exists. If you are testing after the fact then you can apply the same techniques, but often it is harder because you let your understanding of HOW things are implemented infect your scenarios. This results in scenarios that have to much detail in them and are often difficult to implement, because the detail gets in the way of discovering the fundmental abstractions the concisely describe the behaviour. Without these fundamental abstractions creating state can seem more challenging than it actually is.