You mentioned you built an endpoint without authentication that looks like it might output data from your Sugar system, aren't you concerned that someone could find that url, and retrieve information from your system?

If this is an integration between two systems (eg: a website that needs to show the case?), why wouldn't you use the authentication to gain the OAuth token and subsequently pass the OAuth token to the GET API for the Cases module? You wouldn't even need to create a custom API for that, but just leverage the filter API.

There are really really rare cases where you would leverage an unauthenticated endpoint. Same applies from overcoming Team security.

Authentication and authorisation are in place to make sure you authenticate as a specific user and then the system will allow the correct ACL available to the specific user (being that Team visibility or Roles actions).

I do not know and do not have visibility to your full use case, but from what I see and know, something does not feel right...

This is an integration between a customer support ticket system and SugarCRM.

None of the Authentication and SSO options are applicable to SugarCRM, to my knowledge

I would prefer to authenticate, but I didn't see a way here. Please do tell me if authentication is still possible in such a case.

This system sends data to my endpoint when something happens in it, but it can only send once per event, so I cannot make it authenticate with SugarCRM before sending the data. That's why my endpoint is without authentication.

This system sends data to my endpoint when something happens in it, but it can only send once per event

Do you have the possibility to modify the sending end to complete other actions? I suspect you do, otherwise how do you define what is sent and to what url?

In that code you could use the pseudocode:

call login

result = send data to sugar

if(!result) { call login again try again once, if something went wrong due to expired token over time if failed handle password error and stop by showing system is down message}

function call login { get previously leveraged oauth token from local storage if empty retrieved oauth token { execute actual sugar login as the integration user (note that you should use a user with limited permissions, allowing just what it should be doing) You should only login when absolutely needed so that most of the times only one http request between the two systems is executed and get token back or if failed handle password error and stop by showing system is down message store the oauth token in local storage for re-use if valid }}

function send data to sugar { send data to sugar if error { empty oauth token from local storage so that it won't be re-used }}

If you cannot modify at all the code on the sending end, you could have a middleware layer that does the same and actually sends data to Sugar.

You could lock down the middleware so that only the sending service can connect to the middleware (basic auth, header auth, ip whitelist).

If you do not need real-time response to the user, you could just even store the posted info in a local database, and then parse it and send it to sugar at your own time, and then send back confirmation to the user, depending on the specific use case.

Thank you very much for your suggestions! It will definitely be useful to keep in mind these options in such cases, but in this case, the only best option between what I could think of and your suggestions would have been to use a middleware to authenticate a trigger request to SugarCRM and make Sugar retrieve the data from a locked down database - so a combination of two of your suggestions! Just that it was not justified in terms of time for this version of the integration.