If your goal is only authenticity (and not confidentiality), the signature in the header, either from the client or server, or in both directions, can be used to verify that the bits received are from the sender.

Note that if the signed content does not have a timestamp that is checked, it is vulnerable to simple replay which could enable someone in the middle to perform some function or masquerade as the other side indefinitely.

The error "data too large for key size" partly occurs because direct RSA encryption/decryption is computationally intensive so the implementation is not designed to process bulk amounts of data. The actual limit is related to the cryptographic strength guarantees the algorithm provides. Allowing a large, low entropy payload would weaken it.

To avoid this error, you need to use a message digest algorithm that performs a one way hash like MD5 on a larger set of bits, such as the HTTP POST body, and then encrypt the fixed-size digest result using RSA encryption. The encrypted hash is essentially a digital signature. The receiver side then decrypts, computes the hash result of the body, and compares the hashes to verify the signature.

Note that if a session key is available because encryption is also being used, then the hash of the body could be simply be encrypted with that shared symmetric key instead of doing the more costly RSA encryption. This is termed a message authentication code (MAC) and is not as strong as a signature.