When it comes to monitoring APIs, getting a 2xx back is not enough. You have to check that the returned payload is what is actually expected. So, if the expected payload contains 14 language options, it does contain 14 and not 3.
This is another reason why it is also vital to continuously test your APIs – also known as active monitoring. Sure, the API test suite might have passed in both the sandbox and live environments. But if the backend is pulling data off third-party systems (like a hotel price comparison website), there is no guarantee that the data is correct. And this leaves aside previously unseen issues in internal systems that might arise.
Did it REALLY happen? Monitoring APIs can tell you.
But even if you do get back exactly what you expect, it’s still a good idea to check that what you think has happened has in fact happened. If you make a request to transfer money from one account to another or to book a hotel room, you want to make sure that the money really did get transferred or the hotel room booked.
That might mean doing an immediate check against a returned transaction ID. But not all transactions are finalized immediately. Transfers don’t always complete straightaway. A reservation might just end up in a queue somewhere for several hours.
So it can be a good idea to check the transaction the next day. You could even do that by writing an AWS Lambda or Google Cloud function that extracts the transaction ID from the previous day’s result, and calling the function from a workflow.
But the moral of the story is, expect the unexpected. Don’t assume an API works. Don’t assume that because an API works, the backend works. Don’t assume that because something used to work this morning, yesterday, last week, last month, it still works right now. And keep on monitoring APIs because if you aren’t monitoring, you aren’t managing.
