Import set API vs Scripted Rest API

[1_DipikaD]

Hi All ,

I have doubt on a few questions mentioned below . Please help me to find the answers.

1 -  Where import set Api is used and where scripted rest api is used ?

2 - Which is better Basic or Auth 2.0 ? While token expires how to get new token and is it a manual or automatic process . If it is automatic then how we can configure it ?

3- What is the significance of co-relation id in integration ?

Thank You

[yashkamde]

Hello @1_DipikaD ,

 1) Use Import Set for data ingestion and transformation and Use Scripted for custom integrations :

Import Set API	Scripted REST API
Used for bulk data loads into ServiceNow from external sources	Used for custom integrations and exposing tailored REST endpoints
Works with staging tables and transform maps	Allows custom logic, validations, and controlled responses
Best suited for ETL (Extract, Transform, Load) scenarios	Best suited for real-time integrations and external system communication

2) Use Basic Auth only for internal use cases. OAuth 2.0 is generally better because it avoids exposing static credentials and supports token lifecycle

Basic Auth	OAuth 2.0
Simple, credentials sent with every request	More secure, token-based authentication
Less secure, not recommended for modern integrations	Preferred for modern integrations
No token expiry handling	Access tokens expire; refresh tokens automatically renew
Manual credential management	Configured in ServiceNow via System OAuth → Application Registry with refresh token handling

Refer this for detailed understanding :

What is Difference between table api , import set api and scripted rest api with example ? 

Basic Authentication vs OAuth 

Correlation ID 

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

[Ankur Bawiskar]

@1_DipikaD 

responses inline

1 - Where import set Api is used and where scripted rest api is used ? -> scripted rest api is used when 3rd party wants to send request in particular format and response is required as per their format, import set API is mostly used to load data to table

2 - Which is better Basic or Auth 2.0 ? While token expires how to get new token and is it a manual or automatic process . If it is automatic then how we can configure it ? -> OAuth 2.0 is better in terms of security as compared to Basic auth. Before the access token expires 3rd party will have to generate the token again using refresh token. If you are consuming 3rd party using OAuth 2.0 then same process you need to follow

3- What is the significance of co-relation id in integration ? -> it's used to store the unique identifier of 3rd party during integration

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Tanushree Maiti]

Hi @1_DipikaD 

1. When to Use Import Set API vs Scripted REST API

Use Import Set API when:

• Best suited for high-volume data imports or scheduled synchronization from third-party applications.
• You want to leverage Transform Maps, Coalesce fields (to automatically insert or update records), and Transform Scripts instead of writing custom processing logic.
• The external application only needs confirmation that ServiceNow has received and staged the data, while record processing happens asynchronously in the background.
• You want a built-in audit trail because the raw incoming data is temporarily stored in the Import Set staging table, making troubleshooting and reprocessing easier.

Use Scripted REST API when:

• A single request must perform complex business logic, such as:
• Querying multiple tables
• Performing conditional validations
• Creating or updating multiple records
• Triggering Flow Designer or business processes
• The third-party application requires a custom request or response format, custom HTTP status codes, or specific error messages that standard APIs cannot provide.
• The incoming payload contains nested parent-child data (for example, an Incident with multiple Tasks or Work Notes) that must be processed immediately into different tables.
• Integrating with systems like GitHub, Azure DevOps, or monitoring tools where webhook payloads require immediate parsing and server-side processing.
• You need complete control over authentication, logging, request validation, or want to identify the source system through custom logic.

Key difference: Import Set API focuses on data loading, while Scripted REST API focuses on custom business logic and integrations.

2.Why OAuth 2.0 is Better than Basic Authentication

OAuth 2.0 is more secure than Basic Authentication because it does not send a username and password with every request. Instead, it uses:

• Access Token – Short-lived token used to access protected resources.
• Refresh Token – Used to obtain a new access token when the current one expires.

Benefits

• Credentials are not repeatedly transmitted.
• Access tokens have limited validity, reducing security risks if compromised.
• Access can be revoked without changing the user's password.
• Supports secure delegated access between applications.

If the Refresh Token Expires

If the refresh token also expires or is revoked, you must re-authorize the application with the OAuth provider to obtain a new access token and refresh token.

In ServiceNow

1. Navigate to System OAuth → Application Registry.
2. Verify that the Client ID and Client Secret are correct.
3. Open the appropriate Connection & Credential Alias.
4. Click Get OAuth Token to perform the initial authorization and obtain new tokens.

3. A Correlation ID is a field used to store the unique identifier of a record from an external system.

It is not a Reference field type. It is typically a String field that stores the external system's record ID.

Purpose

• Links a ServiceNow record with its corresponding record in another system.
• Prevents duplicate record creation during integrations.
• Enables updates to the correct existing record.
• Supports bidirectional synchronization between ServiceNow and external platforms.

Example

• ServiceNow Incident Number: INC0012345
• ServiceNow sys_id: 46d44f...
• Jira Issue Key: PROJ-123

Store PROJ-123 in the Correlation ID field. Later, when Jira sends an update for PROJ-123, ServiceNow searches the Correlation ID field and updates the correct incident instead of creating a new one.

[EmiliaP]

Adding some depth on the correlation ID question, since it's easy to under-explain and it's actually the piece that makes an integration reliable long-term.

Why it exists

Two systems don't share a primary key. System A has its own internal ID for a record, System B has a completely different one, and neither knows the other exists by default. A correlation ID is the value you deliberately store on both sides so that both systems agree: "this record over here is the same logical thing as that record over there."

Without it, the only way to match records is by guessing at business fields (title, description, timestamps), which is fragile and breaks the moment someone edits a field the matching logic relies on.

Where it actually earns its keep: retries and replays

The significance isn't really about the first sync, it's about every sync after that. Real-world integrations fail mid-flight constantly: timeouts, rate limits, network blips, a downstream system being temporarily down. When that happens, the safe response is almost always "retry" or "replay this batch again." That's exactly the moment correlation IDs matter:

• On the first, successful attempt, the integration creates a record and stores the correlation ID.
• If that same message gets retried (because the sender never got a confirmation, say), the integration checks for the correlation ID first. It finds a match, so it updates the existing record instead of creating a new one.
• If there's no correlation ID persisted anywhere, the integration has no way to know attempt #2 refers to the same event as attempt #1. It just sees "a new record to create" and creates a duplicate.

The same logic applies to reprocessing: replaying a batch from yesterday, backfilling after an outage, or manually resubmitting a failed queue. Every one of these depends on being able to say "have I already handled this exact logical record?" and correlation ID is what answers that.

What breaks without it

Two failure modes show up almost immediately once you drop or lose correlation IDs:

• Duplicates: the same source event gets processed more than once and creates multiple downstream records instead of one, which pollutes reporting, breaks SLAs tied to record counts, and confuses anyone trying to reconcile the two systems.
• Orphaned records: an update comes in for a record that was created earlier, but the integration can't find the original because the link was never stored (or got overwritten/cleared). So instead of updating record A, it either creates record A2 or silently fails to apply the update, and now the two systems have drifted out of sync with no clean way to reconcile without a manual data cleanup.

Both failure modes tend to be invisible at first (nobody notices for weeks) and expensive later, because by the time someone catches it, there can be thousands of duplicate or half-linked records to untangle.

A couple of practical notes, still system-agnostic:

• The correlation ID should be stored on both sides if possible, not just one. That way either system can initiate a lookup instead of always depending on the same direction of sync.
• It needs to survive edits. If a business field changes on either side, the correlation ID shouldn't move or get regenerated, since it's an identity anchor, not a data field.
• For anything asynchronous (queues, webhooks, scheduled batch jobs), treat "at least once delivery" as the default assumption, and let the correlation ID be your idempotency check rather than assuming messages only ever arrive once.

One more thing worth flagging: once you're stitching more than two or three systems together this way, most teams eventually want one place that owns the correlation ID convention instead of re-inventing the matching logic separately for every point-to-point integration. Worth keeping in mind as the integration landscape grows past the first couple of systems.

Hope that fills in the gap on the "why" behind correlation IDs.