The answer in two lines
An API is a service door into a program, opened on purpose so that another program can come in and take data or leave data without going through the screens you use. If your business software doesn't have one, the work can be automated all the same, by coming in through the front door, which is the same screens a person opens
So the right question isn't whether you have an API, it's whether the work you do by hand has volume and clear rules. The rest is a question of how you get in
The service door, and why it often isn't there
Think of the back of a warehouse. The main entrance is for people, with the reception desk, the signs, the stairs, while round the back there's a narrow door with a delivery note to sign and nothing else, and whoever comes in that way already knows what to collect and where it is
The API is that door. Whoever built it decided in advance what can be taken, what can be left, and who holds the key
That door isn't there by accident, though, it has to be built and it has to be maintained, and for a business software vendor that's work nobody sees and nobody asks about at the moment of the sale
So very often that door simply doesn't exist, because the program was born when the question didn't come up. Other times it exists but is paid for separately, maybe as an extra module or a contract of its own. And it also happens that it's there, free, but only opens onto half the warehouse, it lets you read the customer records and the documents, and the one thing you need stays on the other side of the wall
If the door is there we use it, if it isn't we come in the front
When an API exists, is documented and covers what's needed, that's the one we use, not for fashion but for solidity: it's faster, it doesn't depend on where a button sits on the screen, and it holds up better when the program is updated. Ignoring it just to show how clever we are would be silly
When there's no API, or it only covers part of the job, Muffin Suite comes in through the front door, which means it opens the screens of your business software the way an operator would, types into the fields, clicks, saves, and checks that what got written is the right thing
This way of working is the house specialty, and it works for a simple reason: the screens are always there, by definition. If a person can do that job, then the steps to repeat exist, and an old program that never changes its appearance is an excellent candidate for exactly that reason
There's a page of its own on how to choose between the two roads case by case, direct integration or working through the screens, and another on automating programs with no integrations
What to do when someone tells you that
If your supplier answers that nothing can be done without an API, that sentence almost always means that he doesn't do it with his product, which is useful information but a different thing
There aren't many questions to ask whoever offers you an automation. Is there an API for this program, what does it cover and what doesn't it, is it paid for separately, and if it isn't there or isn't enough, how do you intend to get in. Anyone who answers those four points calmly is thinking about your case