Would like to deactivate the API that are not usufull for my instance

[oneveu]

Hi gurus,

Wondering if better than making the security of the API we dont use on ACL, it should not be better to deactivate them, for example we have more than 200 active Scripted Rest API. Should we not deactivate them?

How to guess the ones usefull for the OOB features compared to the ones that are active in case of ???

Looking for some guidance.

Regards

[vaishali231]

hey @oneveu 

Before deactivating any Scripted REST API, I would suggest checking the below points first:

Separate Custom vs OOB
Start with custom Scripted REST APIs. Be very careful with OOB APIs, as they may be used internally by platform features, Store apps, Mobile, Virtual Agent, or Flow Designer.

Check usage history
Review transaction logs and filter for /api/ calls over the last 30–90 days to confirm whether the endpoint is actually being used.

Search for references
Perform a global search for the API namespace in:

Flows

Script Includes

Scheduled Jobs

Widgets

Integration configurations

Use a phased approach
Instead of immediate deactivation, restrict access (e.g., admin-only) and monitor for a period. If no impact is observed, then proceed with deactivation.

*************************************************************************************************************
If this response helps, please mark it as Accept as Solution and Helpful.
Doing so helps others in the community and encourages me to keep contributing.

Regards
Vaishali Singh

[lauri457]

The security of the platform is way more likely to be compromised by something custom rather than anything oob. Not saying that everything sn made is without fault. But you are way better off focusing on anything custom built, governance of users or machine identities etc.

[AnkaRaoB · Accepted solution]

Hi @oneveu ,

If you have many active Scripted REST APIs (e.g., 200+), it is not recommended to deactivate them blindly, as many OOB and plugin features depend on internal APIs.

Key Recommendations:

1. Do not deactivate first

   • Disabling APIs without analysis can break integrations, mobile apps, Virtual Agent, or platform features.

   • Always analyze usage before taking action.

2. Secure APIs before considering deactivation

   • Enforce strong authentication (OAuth/JWT where possible).

   • Require roles on every API.

   • Add script-level role checks for defense in depth.

   • Remove any anonymous/public access.

3. Identify which APIs are used

   • Review transaction logs (syslog_transaction) for /api//traffic.

   • Check OAuth Application Registry for active consumers.

   • Review application scope and plugin ownership.

   • Look at update set history and creator info.

4. Differentiate OOB vs Custom APIs

   • OOB APIs are usually scoped, protected, and tied to plugins.

   • Custom APIs are often in global scope, editable, or use custom prefixes.

   • Prioritize review of custom APIs.

5. Establish an API Inventory
   Maintain a list with:

   • API name

   • Application/scope

   • Business owner

   • Last used date

   • Auth method

   • Required roles

   • Status (Active/Deprecated/Retired)

6. Monitor before retiring

   • After securing, monitor usage for 30–90 days.

   • Tag low-use or dormant APIs.

   • Notify stakeholders before disabling.

7. Deactivate safely
   Only deactivate when:

   • No usage for 90+ days

   • No active OAuth clients

   • No known business owner

   • Not OOB or platform-dependent

   Always test in sub-prod first.

Rule of Thumb:

If an API is authenticated and role-protected, it is already secure.
If it is unused and undocumented, plan to retire it.

If this response helps, please mark it as Accept as Solution and Helpful.

[vaishali231]

hey @oneveu 

Hope you are doing well.

Did my previous reply answer your question?

If it was helpful, please mark it as correct ✓ and close the thread 🔒. This will help other readers find the solution more easily.

Regards,
Vaishali Singh