The problem with the approach of phoning the school and asking for confirmation is exactly as stated earlier – if the caller has a legitimate purpose, then the call would seem to pose no problem in revealing the yes/no to the caller, but revealing information about attendance of a vulnerable person at a particular institution to an unknown caller has plenty of hazards if the caller happens to not be who they say they are.
Having built systems that have to operate in such circumstances, where the identity of the "caller" cannot be readily validated (in this case the person on the other side of an API who is a minor or vulnerable person who is collecting user credentials, so cannot yet authenticate themselves), this is not only hard... it is challenging to design a system that is sufficiently robust to prove the party on the other side is indeed who they say they are. First/last name and date of birth can readily be known by others, and acceptance of such credentials to provide the service is sufficient for an existence proof to be made to the caller. That could have an unpredictable real-world impact.
It's also surprisingly difficult to convey this hazard to those who design such systems, with plenty of examples out there cited as "competitor X does it, so why can't we?". The world and peoples' lives are surprisingly colourful and difficult at times, and while the risk may be low, I wouldn't want to design a system where information can be leaked without knowing very sure the party on the other side is who they claim to be.
An ID number on the ID card or some other piece of unique data might help reduce the risk – but seems unlikely a protocol would have been implemented to check such data for such a rare usecase.
The risk might be low, but it's these edge cases that are vitally important to design in. Similar with designing legislation – might be fine for the author, but needs to be tested against all other legislation and potentially underrepresented groups. Well, that's the theory anyway, right?