Systems and their APIs should be
- obvious
- predictable
- and communicative
This is for example described in Evans' "Domain-driven design" (e.g. chapter 10, "Supple design"). I think these ideas are a good rationale even out of the scope of DDD.
Functions should be side-effect-free, which means that they should do exactly one thing. So I think your function "createImagePack" should not have the unobvious side effect of creating an artist.
Your API could be predictable by having intention-revealing interfaces.
What is your API anyway? Seems to me that you should have separate domain model classes for artists, images, image packs ... If there is a convenience method that abstracts the handling on a higher level it should be a facade. But the naming should clearly communicate what it does.
Perhaps you should even go one step back and look at your application's domain. Maybe your application should never do any handling of images or image packs without an existing artist. Perhaps it should be more like [artist] -> [create image pack]. This could be more obvious than the other way round!
Am I over analyzing this?
I don't think so.
Is their literature of good write-ups on what is the best course of action here?
You could have a look into DDD ideas. Even if you don't design your application the DDD way.
Another possibility was to look at test-driven development. If you design your application for testability, you will likely want to have a good separation of concerns, too -- without side-effects.
Fendy: If you separate the API as two calls, how can you handle if the second webservice is error while the first one success?
Is he really talking about an API at the webservice level? Where do the artists come from? I think when a painter uses this cloud service he is the artist and when he authenticates with the system there should already be an artist entity?