API Server - who will be able to see our different API paths/Endpoints?

Hello,

With the API Server, it is possible to create the path one wants, so that the paths/endpoints are intuitive. If we have multiple clients, we could have paths different endpoints like:

web-api/client1/task1
web-api/client1/task2
web-api/client1/task3
web-api/client2/taskA
web-api/client2/taskB

This is more intuitive, however at the same time the name of the client appears in the Path. For those IPs that have access to our API Server, can they “see” all our API endpoint structure? We wouldn’t be interested in that. For example, for client2, we may be triggering a task for them using the endpoint “web-api/client2/taskA” - on their end they shouldn’t be able to list out or explore the other endpoints that we have in our Web API (those from client1, for example).

How does the API endpoint exposure work, and until what point can an IP with Access to our server see or list all the other endpoints that we have?

Regards,

Roberto

There is no public API for listing all endpoints.

However, the API is public by definition, which means everyone can send a request to any endpoint as long as they know the URL.

Protect endpoints with an API key, so that only authorized clients can use their respective endpoints.

So you mean that if someone with a specific IP address that has access to our server tries to list all the URLs inside our server (including API endpoints) using a website crawler or any other tool to list all the possible links of a website, it won't work, right? Here's a StackExchange link where different ways of obtaining a website "directory tree" are listed:

And here we're always referring to the specific IPs that have access to our server, right? The IPs that don't have access directly won't be able to connect to the server in the first place, so no way of obtaining any info.

Thanks,

Roberto

API Server does not have a public endpoint that would return a list of API endpoints. However, the client can try to “guess” the correct URL. Therefore, it is better to use additional authentication (API keys). Obviously, if a user has access to a space, or access to a space public folder, then such a user can find out the list of endpoints in such a space.

How do your clients call the created API endpoints? Do clients directly open a URL like “web-api/client1/task1” in a web browser? Or are they using some third-party solution to call the Endpoint API?

And are there any difficulties using the API Server? Like canceling a request or parameters binding?

Hello,

Our clients will call the endpoints via a third-party solution, mainly directly through Salesforce, and in some occasions they may do so directly through the browser. We are currently reviewing how this will work.

What do you mean by this? We haven't encountered issues as we're setting it up, but can you give me more information as to what you're referring to here?

Thanks!

I mean that in the current implementation, canceling the request by the client leads to underhood computation cancellation.
The header and URL parameter assigned as the module parameter must always be present in the request.
Is this behavior understandable and expected?

Ok. Yes that behavior is understandable, if I find anything along the way I will inform you :slight_smile:

Thanks!

1 Like