“What’s the version of your Mule API?” you might be asked one day. On the surface, you would think it’s such a trivial question, but if you think again, you would know there is much to more to the story. The truth is, there are a few “versions” of the same Mule API depending on what you’re referring to. In theory, an API version is the version of the API interface. The interface definition is a contract that declares what the API can and shall do. MuleSoft uses RAML to define the API interface. There is a “version” attribute in RAML file specifies the version of the API. RAML is the equivalent of WSDL in the SOAP world, or IDL for Java RMI. Once it is published, it should stay as stable as possible unless you absolutely have to change it, because changes may break existing clients. However, in the real world, we do make changes to the interface. If the interface has changed, the version number should be updated. In an ideal world, the “version” defined in the RAML should be the single version # we ever use to refer to this API interface anywhere. However, the real world is little bit more complicated. Let’s take a look at the life journey of an API version and its different incarnations in the Mule world. When RAML (which should have a version in it) is used to generate an API project, Anypoint studio will use the RAML file to create a skeleton flow of the API project. The RAML file is placed under “src/main/api”, and the API main flow will contain an “apiRouter” flow that routes the HTTP request based on the RAML definition. For the sake of this discussion, assume the RAML has two REST resource paths.