Here are my "off the top of my head answers", which may change after I give it more thought.
1) I'm not sure if there is much point to a salt here. In normal usage a salt protects a leaked password database against rainbow attacks. That certainly isn't relevant here, and moreover I don't think there is any other reason for the salt.
2) Hashing also doesn't add a whole lot of security, I think. Hashing is used to hide a secret during storage, not transit. If you hash it and pass along the hash, then that means your hash effectively is your secret, and a stolen hash is no less dangerous than a stolen secret. Therefore, in a very real sense, you might as well just send the secret itself, especially since it will change regularly.
In summary, you effectively have two defenses in place: a shared secret (which changes), and IP white-listing. Your shared secret is going to be primarily vulnerable to things like replay attacks or request eaves-dropping: if anyone happens to see it in transit, they will know the secret until it next changes. You mentioned this is system-to-system, so depending on whether or not your systems are in the same security zone will probably determine whether or not such a request needs to happen over TLS/SSL. If these systems are communicating between data-centers, you'll probably want to be communicating exclusively over TLS/SSL.
Your second level of security is via IP white-listing. This is primarily vulnerable to IP spoofing, which, depending on your network setup, may or may not be be an issue. I'm sure there are more options as well, but I'm not a network expert.
For a completely different approach you can try implementing a handshake. The basic idea is that when server A sends a request to server B, server B validates the request by contacting server A directly, passing it the full request that it received, and getting back a YES/NO response (the "no" obviously being returned if server A did not send the request in question). Only once it receives the "YES" does it actually process the request. This takes more effort to setup and also takes more network/server resources, so may not be preferable depending on your application needs. The advantage is that it rules out IP spoofing, and also makes the secret exchange unnecessary. However, it may not prevent more direct network attacks (i.e. MITM and the like).
Edit to add:
The handshake idea isn't actually my own. I've used that general flow in my applications to validate server-to-server notifications. The idea itself I stole from paypal (it is how they validate their IPNs), although it probably isn't originally their idea either. I point this out simply because it is a practice that has been in use for a long time, so you can both read their documentation to understand the flow and (potentially) look for information about past security issues that may have arisen due to that flow. Presumably though, since paypal relies on it for a critical part of their payment infrastructure, it is fairly secure:
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNImplementation/
