MAC addresses are not unique
There can be, and will be duplicates with MACs. There are several reasons for that, one being that they need not be (globally) unique.
The MAC must be unique on the local network, so ARP/NDP can do its job, and the switch knows where to send incoming datagrams to. Usually (not necessarily) that precondition is fulfilled and things work just fine, simply because the likelihood of having two identical MACs on the same LAN, even if they are not unique, is quite low.
Another reason is that there simply exist more devices than there are addresses. While 48 bit addresses sounds like there's enough addresses for everybody until the end of days, that's not the case.
The address space is divided into two 24-bit halves (it's slightly more complicated, but let's ignore the petty details). One half is the OUI that you can register with the IEEE and assign to your company for around 2000 dollars. The remaining 24 bits, you do whatever you want. Of course you can register several OUIs, which is what the bigger players do.
Take Intel as an example. They have registered a total of 7 OUIs, giving them a total of 116 million addresses.
My computer's mainboard (which uses a X99 chipset) as well my laptop's mainboard as well as the mainboard of every x86 based computer that I have owned during the last 10-15 years had an Intel network card as part of the chipset.
Certainly there's a lot more than 116 million Intel-based computers in the world. Thus, their MACs cannot possibly be unique (in a sense of globally unique).
Also, cases have been reported of uh... cheaper... manufacturers simply "stealing" addresses from someone else's OUI. In other words, they just used some random address. I've heard of manufacturers that just use the same address for a complete product range, too. Neither of that is really conforming or makes a lot of sense, but what can you do about it. These network cards exist. Again: The likelihood that it becomes a practical problem is still very low if addresses are used for what they're intended, you need to have two of them on the same LAN to even notice.
Now, what to do about your problem?
The solution is maybe simpler than you think. Your IoT devices will most probably need some notion of time, usually time is automatically obtained via NTP. The typical precision of NTP is in the microsecond range (yes, that's micro, not milli). I just ran
ntpq -c rl to be sure and was told 2-20.
The likelihood of two of your devices being turned on for the first time at the precise same microsecond is very low. It's generally possible to happen (especially if you sell millions of them in a very short time, congratulations on your success!), sure. But it's not very likely -- in practice it will not happen. Thus, save the time after first booting up on permanent store.
The boot time of your IoT device will be the same on every device. Except that's not true at all.
Given a high resolution timer, boot times are measurably different even on the same device, every time. It's maybe only a few clock ticks different (or a few hundred thousand, if you read something like the CPU's time stamp counter), so not very unique altogether, but it sure adds some entropy.
Similarly, the time it takes
connect to return the first time you access your API site will be slightly, but measurably, different every time. Similarly,
getaddrinfo will take a slightly different, measurable amount of time for every device when looking up your web API's hostname for the first time.
Concatenate those three or four sources of entropy (MAC address, time of first power-on, time to boot for the first time, connect time) and calculate a hash from that. MD5 will do just fine for that purpose. There, you're unique.
While that does not truly guarantee uniqueness, it "pretty much" guarantees it, with a neglegible chance of failure. You would have to have two devices with identical MACs that are turned on for the first time on the same microsecond, and took the exact same time to boot, and to connect to your site. That isn't going to happen. If it does happen, you should immediately start playing the lottery because to all appearances, you're guaranteed to win.
If, however, "will not happen" is not good enough as a guarantee, simply pass each device a sequentially increasing number (generated on the server) the first time they access your web API. Let the device store that number, done.