If you've spent enough time around software engineers you've probably heard the word "endpoint" and thought to yourself "why does everything these people talk about sound so confusing?". Well endpoints are really straightforward when you cut out all the technical jargon.
When you look at software development, you can basically break it down to; frontend (the part you can see), backend (the part that performs the complex logic stuff that provides the data or response you're seeing when you do certain things on the frontend) and the server (the side with all your data). Because these three major parts are built separately, they tend to end up as three standalone solutions.
The backend makes use of API (Application Programming Interface) to work with the Frontend, however this API has limits, it can do anything except you tell it where to go. It already has built in instructions to perform but it just needs a location to the server it needs to get the data it will work with. The address or link to that resource that the API will manipulate or work with is an endpoint it kinda sound very similar to a final bus stop.
Now the average user gives the API an endpoint by interacting with the frontend, when you click the search button on Twitter when looking for a particular person, you've more or less told the API to get a particular data and you've also specified the server to be searched. You've told the API "go to the database with all the Twitter usernames and bring back all usernames that look like the username I wrote in the search bar". Normally, the API knows how to return data to the frontend, what is always missing is where to go look for that data, the endpoint is the address to the database you want the API to look through.
Note that all of the above are just a very simple way to look at things (using API endpoints as an example). There are various ways endpoints are used but at the very core its just about the address to a place where an API can get some data, manipulate it and return it to the frontend.
A final example that I hope will make sense enough is using plumbing for an example. You have your taps in your home that gives you water (in a way), however you know that there are pipes in your walls and around your building that transports the water to the tap (this is like the frontend because you interact with it directly by touching it), the pipes are the API in this case (you don't interact with them directly), the water is the data. The data comes from a source or storage container (that source or storage container is the database or server). There are many sources of water all over the world, your pipes have to be connected to a particular one to get water, when you open a tap in a particular home you've more or less specifically told the pipes in that home to bring water from a particular storage. Not all pipes and taps have the same source of water, some pipes connect to the water closet of the toilet, some pipes connect to the water heater and some pipes connect to the main water storage for the house or even a community (for those who have a centralized water storage).
When you press the flusher in the toilet, you've told the pipes involved to bring water from the water closet it is connected to, going to another toilet will give you water from a different water closet. The same thing applies to water heaters and their taps. This is how APIs work if you look at the storage/water closet as the database, the tap/flusher you press/pull as the frontend and API as the pipes connecting the tap/flusher to the storage/water closet.