Maybe You can improve with multiple functions… like this

defp parse_markets(response, "Market1"), do: #whatever
defp parse_markets(response, "Market2"), do: #whatever
defp parse_markets(response, "Market3"), do: #whatever
defp parse_markets(response, _), do: #whatever

Also while there is nothing wrong with comprehensions it seems that your are holding on too tightly to iteration.

If you are going through the list for side effects I’d expect to see Enum.each/2 instead or if you wanted conditional transformation I’d expect some piped combination of Enum.filter/2 and Enum.map/2 (though comprehensions can have filters as well).

At the very least I’d make the comprehension look less like a loop, e.g.

def get_markets, 
  do: for {name, url} <- get_market_urls()
          do: get_market_data(name, url)

vs

def get_markets,
  do: Enum.map(get_market_urls(), fn {name,url} -> get_market_data(name,url) end)

or

def get_market_data({name,url}) do: 
  ...
end

def get_markets,
  do: Enum.map(get_market_urls(), &get_market_data/1)

(In general I’d dial back on the use of inline anonymous functions that is so common in JavaScript)

As all your branches do compare for equality of market against a string literal a case were much more idiomatic.

Also I’m not quite sure why in the parse_markets/2 you are returning :ok (an atom) most of the time but "Other" (a string) on unknown markets.

A “Clean Coder” advice: I would prefer the pattern-match solution by @kokolegorille for one reason: You can add new “Markets” without changing the existing code but by just adding a new function-header for “Market4”.