CAN transmission and message IDs
CAN messages always contain either a 11 or 29 bit ID.  How you use that ID, if at all, is up to you.

If you only have two nodes, and one of them only ever sends one message, then the other node could ignore the received ID entirely and just process the message according to the one and only format it can be.  However, this is really bad, I'd say downright irresponsible, system architecture.  It would be much better to look at the ID and discard messages that don't have the expected ID.  This is a very easy thing to do, so there really isn't any excuse for not doing it.

A node that responds to a remote request for ID 500 by sending a message with ID 3 is either broken or also irresponsibly designed.  I can't imagine any commercial product doing this.  It might be a good idea for the requesting node to send requests for both 500 and 3 just in case, and be prepared to handle responses with either ID.  Maybe someday the stupidly designed node will be fixed or upgraded.  If the requester at least follows the rules, then there is less chance of a problem later.

However, I'd seriously consider finding a alternative for a node that responds with 3 to a request for 500.  Something that irresponsibly designed most likely has other problems.  Run away.