To be honest, it's almost impossible to know for sure unless you've been told.
If you go way back to some very old 3d games like Doom, they didn't use a 3d api to make 3d games. They used a 2d API (probably drawing directly to the video frame buffer). It manually did what is now built in to graphics cards. There isn't really anything limiting you by using a 2d API except for the speed of your processor and your own knowledge of 3d mathematics.
Going the other way, a programmer can ignore basically all 3d accellerated features of their API to make their 2d game. The programmer would use 'textured quads' to draw 2d sprites. Once that's implmented all the programmer needs to do is say "draw this sprite at this location" to make their 2d game.
All that being said, there are often hints when seeing a 2d game whether it uses a 3d API under the hood. Rotating sprites is a costly process without using a 3d API in some way. So if you see a lot of rotation it's probably using 3d api. If you see things like the view smoothly zooming in and out on the action that's probably using a 3d API. If you see transparency changes (fade in/out) it's probably using a 3d API. But again, that's all possible without a 3d API.
Things are further confused because a 2d API might be implemented using a 3d API. SFML is implemented in OpenGL for example (and uses that 'textured quads' thing). Because it uses OpenGL, rotating and zooming and using transparency in SFML is simple and fast. SDL was not implemented in a 3d api so you can only do rotating and zooming manually or by getting an add-on, that also does it manually. While SDL allows interoperability with OpenGL, It just creates the window and then the programmer switches to using OpenGL functions so it's mainly just to help set things up in that situation.