I'd think of this site-specific key as being analogous to a session key that might be used in a conventional secure system. With that, the basic idea seems secure enough, and the main concerns that I see are some of the deeper complexities that you may or may not have:
Are there multiple logins for each web property? Do they get created and deleted, and by who? If not, can you be sure that there will never be? Because if there are, now or ever, then all users will have the same session key, so you don't know which specific user accessed the data when, and you don't have a good way to revoke access when a user quits or something.
One fix would be to have the Wordpress backend call out to the node server, all right, but if that's non-viable, then the next best IMHO would be:
Get the front-end script a user-specific token, and query to the node server with that, and possibly a site identifier too. The node server queries the Wordpress server somehow to validate that the user currently has permission to access the data for that site. This might possibly be doable with no extra backend code, depending on if the current Wordpress front-end has a way for you to get a user identifier, and if there's already a way to make some kind of call sequence to Wordpress with that user identifier that confirms that it is valid and currently has access rights to a specific site.