UML deployment diagrams (using only the notation defined in the OMG specification) can contain notes as well as annotations on the associations between nodes. You can add directionality to the associations if it helps, but do consider the nature of the communication - even if you aren't sending messages back and forth, the underlying protocol may.
A UML component diagram may also be useful. You can show the interfaces between components in the system, this will provide a useful notation. You can relate components to elements on the deployment diagram as well.
If you want to show a flow of communication between nodes, perhaps consider an interaction overview diagram. You can then delegate the specific details of what happens within various nodes to sequence diagrams.
The real question is why you need an "official diagram". First and foremost - consider the needs of your stakeholders. Identify who they are and what information they care about, then choose the appropriate tools to deliver that information.
Using a standardized modeling notation is useful. If you use UML, you don't need to explain your modeling notation to other people. You can simply follow the rules of the language and point people to the documentation. No need to create a key to understand. However, UML isn't the only modeling language out there that is standardized - consider the C4 model (which can use UML for the most detailed models) or ER modeling (which has a few standard notations - Chen's, Bachman's, Crow's Foot).
Also consider the idea of viewpoints and perspectives. In order to satisfy different stakeholders, you may need different diagrams. Perhaps even different diagrams of the same time. For example, in a distributed system, the operations stakeholders may care about things like communication protocols and ports between nodes while development stakeholders may care more about what types of messages flow and their directionality. This may require making two different deployment diagrams for the same system, with different details on each diagram.
You better express that information with a conceptual diagram than a component diagram. Meaning: draw two boxes and connect them directly with a arrowheaded line
Also see : Conceptual Diagram @ Wikipedia
What you are talking about is a very very high level view of a system. Component diagrams are not suitable for such high level views. Component diagrams are required to show all the used public functionalities of components. Being so, they help to understand the interactions between components in one look. So they need to be detailed.
Best Answer
Your external API (the connection to the content management system) is not a class, it's an interface. As illustrated in this Stack Overflow question, it would look something like this: