Contrary to giving a hardware key to some family member the random string you propose is just data and could be easily copied without notice. And while you might feel that the transport of the hardware key in the pocket is sufficient protection the situation is different with data only as the key.
Still, if you protect your data key well it might be secure enough in your environment, although the exact security requirements of this environment are unknown. Protecting the key means at least using HTTPS so that nobody in between client and server can sniff the key.
But even with HTTPS it is enough that a single of the systems having the key gets compromised. In this case the key can simply be copied and misused because all systems use the same key. Assuming that the misuse of this shared key is noticed at all the only option is to revoke this single shared key which means a new shared key need to be distributed to all systems. In this case it would already an improvement if you use a different key for each system since then the impact of misuse is limited and you only need to revoke and update the key for a single client. This scheme of having a different key for each client could be simplified by using client certificates with your own certificate authority and just trusting any certificate issued by this authority.
Client certificates also have the advantage that they could be hardware backed using a smart card or similar. This way an attacker needs to have physical access to the system to steal the key. Compromising the system from remote is not sufficient, but misusing the existing key from remote might be possible if there is no local interaction required for using the key (i.e. always in smart card with no PIN). And even if the attacker manages to get physical access to the hardware key he will probably not be able to copy it with acceptable costs so the loss of the key will be noticed and access to the key could be revoked.