Scripted rest API set-up for ebonding integration

Rupa4 · Monday

Hi Community,

I am working on creating a new Scripted REST API for an Ebonding integration in the [Zurich]

I noticed that the Default ACLs field is now mandatory, which wasn't the case in previous releases. Could help me to handling this part and providing solutions.

vaishali231 · Monday

Hey @Rupa4

In earlier versions, ServiceNow automatically applied a default ACL such as Scripted REST External Default behind the scenes. In Zurich and later, you must explicitly select a Default ACL to ensure proper access control.

What you should do

For your ebonding integration:

Navigate to your Scripted REST API record
Open the Security tab
In the Default ACLs field, select
Scripted REST External Default
Click Update

Why this is required

The Default ACL is used when:

Requires authentication is enabled

Requires ACL authorization is enabled

No resource-level ACL is defined

This ensures that at least one ACL is evaluated before granting access.

Approach

Specific to your use case

Since this is an external ebonding integration:
Use Scripted REST External Default
Use a dedicated integration user (with minimal roles)
Enable authentication (Basic or OAuth)

General best practice

Do not rely only on Default ACLs. For better control:
Create resource-level ACLs for your API
Restrict access using roles like x_company_integration_user
Add conditions or script-based validation if needed

Example ACL script:

answer = gs.hasRole('x_company_integration_user');

***************************************************************************************************************************

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

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

View solution in original post

Pavan Srivastav · Monday

Hello Rupa,

For most bidirectional or inbound ebonding scenarios, it’s advisable to select "Require Authentication" as the Default ACLs setting. Ensure your integration user, which acts as the remote system’s service account, has:

- A dedicated role (e.g., x_your_scope.ebonding_user) or a relevant baseline role like itil, scoped to the needs of your application.

- Write access to your target table (such as incident, change_request, or a custom ebonding staging table).

- Optionally, resource-level ACLs to restrict which endpoints the service account can access.

**Step-by-Step Guide to Creating the Scripted REST API in Zurich**

1. Navigate to System Web Services → Scripted REST APIs → New.

2. Complete the required fields:

- Name (e.g., "EBonding Incident API")

- API ID (auto-populated, editable)

- Application (choose your scoped app or Global)

- Default ACLs (select "Require Authentication"; this is now mandatory)

3. Save the API header record.

4. Under the Resources tab, create a new resource:

- Name (e.g., "createOrUpdate")

- HTTP Method (POST for creating, PUT for updating)

- Relative Path (e.g., /sync)

- Script (insert your handler script)

**Minimal Resource Script Template Example**

The handler script should validate incoming data, check for required fields, update existing records if they exist, or create new ones as needed. The script also returns appropriate status codes and messages to the caller.

**Scoped Application Considerations**

If your Scripted REST API is part of a scoped application, verify that Application Access is set appropriately (either for all application scopes or limited to your own). Additionally, confirm that the integration service account is granted the scoped app’s role, as global roles may not suffice under Zurich’s stricter access controls.

Ultimately, Zurich’s requirement for explicit ACLs is designed to prevent inadvertent exposure of APIs.

View solution in original post

Tanushree Maiti · Monday

Hi @Rupa4

With the Zurich release, the Default ACLs field for Scripted REST APIs is now mandatory, ensuring integrations follow a secure-by-default approach.

This change helps prevent custom endpoints from being exposed without proper authorization.\

Scripted REST API roles

To work with scripted REST APIs, you must have the web service administrator [web_service_admin] role. Users with this role can read, create, modify, and delete scripted REST APIs and web service resources.

Note:

These roles are not required to access a scripted REST API endpoint.

Scripted REST API security

You can configure your scripted REST APIs with the necessary level of security. From public APIs/endpoints that don't require any security to highly secure APIs/endpoints that require user authentication with tight access control to all resources.

Use the API access policy feature to control the authentication method for the APIs. For more information, see API access policy.

Scripted REST API access controls

Access control lists (ACLs) define criteria, such as the roles needed and conditions that a user must meet to access a scripted REST API or endpoint. A requesting user must satisfy at least one of the ACLs. It is not necessary to satisfy all selected ACLs. You can define a single ACL for an entire REST API or for an individual endpoint.

When defining a scripted REST API ACL, it must have the Type value REST_Endpoint.

For additional information on ACLs, see Access control list rules and Configure a scripted REST API resource to require an ACL.

Scripted REST API security matrix

There are multiple possible security configurations for scripted REST APIs. Use this table to identify the scripted REST API security configuration that best suits your needs, and the field values to implement that configuration.

Scripted REST API securityConfiguration Scripted REST API Scripted REST Resource Default ACLs Requires authentication Requires ACL authorization ACLs

The resource is public. No authentication or ACL is required.	Any value	False	Any value	Any value
The resource requires basic authentication only. No ACL is required.	Any value	True	False	Any value
The resource requires basic authentication only. ACL is required.	No ACL selected	True	True	No ACL selected
An ACL selected in the resource record is required.	Any value	True	True	One or more ACLs selected
An ACL selected in the scripted REST API record is required.	One or more ACLs selected	True	True	No ACL selected

Refer: Scripted REST APIs_Zurich

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin:

View solution in original post

yashkamde · Monday

Hello @Rupa4 ,

Basically, this change is designed to ensure that no API is left open to all authenticated users by default. To resolve this and successfully submit your record, you need to associate an Access Control (ACL) of the type REST_Endpoint with your API definition.

How to Resolve the Mandatory Field Requirement :

The most effective way to handle this for an Ebonding integration is to create a dedicated ACL. You can do this by following these steps:

Create a REST_Endpoint ACL: Navigate to Access Control (ACL) and create a new record. Set the Type to REST_Endpoint and the Operation to execute. For the Name, use the same ID you defined for your API (e.g., ebonding_api).
Assign Roles: In the "Requires Role" section of the ACL, add a specific role that your integration user will hold. This ensures only that specific user/system can access the endpoint.
Link to the API: Go back to your Scripted REST API record. Click the Unlock icon next to the Default ACLs field, search for your newly created ACL, and add it to the list.

If my response helped mark as helpful and accept the solution.

View solution in original post

vaishali231 · Monday

Hey @Rupa4

In earlier versions, ServiceNow automatically applied a default ACL such as Scripted REST External Default behind the scenes. In Zurich and later, you must explicitly select a Default ACL to ensure proper access control.

What you should do

For your ebonding integration:

Navigate to your Scripted REST API record
Open the Security tab
In the Default ACLs field, select
Scripted REST External Default
Click Update

Why this is required

The Default ACL is used when:

Requires authentication is enabled

Requires ACL authorization is enabled

No resource-level ACL is defined

This ensures that at least one ACL is evaluated before granting access.

Approach

Specific to your use case

Since this is an external ebonding integration:
Use Scripted REST External Default
Use a dedicated integration user (with minimal roles)
Enable authentication (Basic or OAuth)

General best practice

Do not rely only on Default ACLs. For better control:
Create resource-level ACLs for your API
Restrict access using roles like x_company_integration_user
Add conditions or script-based validation if needed

Example ACL script:

answer = gs.hasRole('x_company_integration_user');

***************************************************************************************************************************

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

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

Rupa4 · Monday

Hi Vaishali,

Thank you for the detailed explanation. Implementing the Default ACL as suggested resolved the issue. Appreciate your support!

Pavan Srivastav · Monday

Hello Rupa,

For most bidirectional or inbound ebonding scenarios, it’s advisable to select "Require Authentication" as the Default ACLs setting. Ensure your integration user, which acts as the remote system’s service account, has:

- A dedicated role (e.g., x_your_scope.ebonding_user) or a relevant baseline role like itil, scoped to the needs of your application.

- Write access to your target table (such as incident, change_request, or a custom ebonding staging table).

- Optionally, resource-level ACLs to restrict which endpoints the service account can access.

**Step-by-Step Guide to Creating the Scripted REST API in Zurich**

1. Navigate to System Web Services → Scripted REST APIs → New.

2. Complete the required fields:

- Name (e.g., "EBonding Incident API")

- API ID (auto-populated, editable)

- Application (choose your scoped app or Global)

- Default ACLs (select "Require Authentication"; this is now mandatory)

3. Save the API header record.

4. Under the Resources tab, create a new resource:

- Name (e.g., "createOrUpdate")

- HTTP Method (POST for creating, PUT for updating)

- Relative Path (e.g., /sync)

- Script (insert your handler script)

**Minimal Resource Script Template Example**

The handler script should validate incoming data, check for required fields, update existing records if they exist, or create new ones as needed. The script also returns appropriate status codes and messages to the caller.

**Scoped Application Considerations**

If your Scripted REST API is part of a scoped application, verify that Application Access is set appropriately (either for all application scopes or limited to your own). Additionally, confirm that the integration service account is granted the scoped app’s role, as global roles may not suffice under Zurich’s stricter access controls.

Ultimately, Zurich’s requirement for explicit ACLs is designed to prevent inadvertent exposure of APIs.

Tanushree Maiti · Monday

Hi @Rupa4

With the Zurich release, the Default ACLs field for Scripted REST APIs is now mandatory, ensuring integrations follow a secure-by-default approach.

This change helps prevent custom endpoints from being exposed without proper authorization.\

Scripted REST API roles

To work with scripted REST APIs, you must have the web service administrator [web_service_admin] role. Users with this role can read, create, modify, and delete scripted REST APIs and web service resources.

Note:

These roles are not required to access a scripted REST API endpoint.

Scripted REST API security

You can configure your scripted REST APIs with the necessary level of security. From public APIs/endpoints that don't require any security to highly secure APIs/endpoints that require user authentication with tight access control to all resources.

Use the API access policy feature to control the authentication method for the APIs. For more information, see API access policy.

Scripted REST API access controls

Access control lists (ACLs) define criteria, such as the roles needed and conditions that a user must meet to access a scripted REST API or endpoint. A requesting user must satisfy at least one of the ACLs. It is not necessary to satisfy all selected ACLs. You can define a single ACL for an entire REST API or for an individual endpoint.

When defining a scripted REST API ACL, it must have the Type value REST_Endpoint.

For additional information on ACLs, see Access control list rules and Configure a scripted REST API resource to require an ACL.

Scripted REST API security matrix

There are multiple possible security configurations for scripted REST APIs. Use this table to identify the scripted REST API security configuration that best suits your needs, and the field values to implement that configuration.

Scripted REST API securityConfiguration Scripted REST API Scripted REST Resource Default ACLs Requires authentication Requires ACL authorization ACLs

The resource is public. No authentication or ACL is required.	Any value	False	Any value	Any value
The resource requires basic authentication only. No ACL is required.	Any value	True	False	Any value
The resource requires basic authentication only. ACL is required.	No ACL selected	True	True	No ACL selected
An ACL selected in the resource record is required.	Any value	True	True	One or more ACLs selected
An ACL selected in the scripted REST API record is required.	One or more ACLs selected	True	True	No ACL selected

Refer: Scripted REST APIs_Zurich

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin: