I am not aware of an elegant solution for this in the context of openHAB, but I think adding such a thing would be great. A kind of “credentials wallet service” that any add-on code could read and write from, that lives on disk in encrypted form and could be unlocked at runtime. In the meantime, you would have to write your own in either the rule/script language, or in Java (where the classes are somewhere in the classpath or an OSGi bundle/service you create, bundle:install and bundle:start).
The tl;dr is create an Item which you send a command to. This Item triggers a rule to do the action. So in this case I would have a Notification String Item and I’d sendCommand(Message) and centralize all my NMA triggers in the one rule that gets triggered by the Notification action.
This is a great way to centralize notification and alerting logic so you don’t have to spread API logic all over the place and it makes it easy to swap your alerting out if you decide to use other services. It also lets you set up logic so at certain time of day you can alert in one way and use an alternative at other times of day (e.g. use NMA during the day but sendMail at night).
Thank you very much for sharing you approach, design patterns to use in order to provide scalability and maintainability was one of my next TODOs… here is a very good start.
Furthermore, as far NMA is concerned, in my case there will be more than one API key : your architecture principle let me define as much API keys as I need and use them in a centralized place.
@rlkoshak’s ideas about improving notifications from rules are spot on. Another approach along the same lines is to use mqttwarn for all notifications: just publish a message to a topic on an MQTT broker, and mqttwarn is configured to dispatch to the correct notification system.