How to Trigger a ServiceNow Flow from an External System via REST API

One of the most common integration requirements in ServiceNow is letting an external system kick off a workflow. A deployment pipeline completes and needs to create a change request. A monitoring tool detects an anomaly and needs to create an incident. An HR system onboards a new employee and needs to provision access. In each case, an external system needs to say "start this process" — and ServiceNow needs to respond.

There are several ways to implement this. The cleanest, most maintainable, and most production-ready approach is the REST API trigger in Flow Designer. It gives the external system a dedicated endpoint, handles authentication properly, runs the flow asynchronously, and provides full execution visibility through Flow Designer's built-in logging.

The Three Approaches — and Why REST API Trigger Wins

Before building, it is worth understanding why the REST API trigger is the right choice over the alternatives.

Option 1 — Table API insert on a trigger table. Create a custom table, have the external system POST a record to it via the Table API, and run a Business Rule on insert to start the workflow. This works but has problems: you are creating and maintaining a custom table purely as a message bus, Business Rules are synchronous and can block the response, and there is no visual execution log.

Option 2 — Scripted REST API. Build a custom REST endpoint that calls FlowAPI.startFlow(). More flexible for complex input processing but requires custom scripting, testing, and maintenance. Justified when you need complex payload transformation before starting the flow.

Option 3 — REST API Trigger in Flow Designer. ServiceNow generates a dedicated endpoint URL for the flow automatically. The external system POSTs to it. No custom table, no custom endpoint, no Business Rule. The flow handles everything. This is the correct default choice.

Step 1 — Create the Flow with a REST API Trigger

Navigate to Flow Designer (Process Automation > Flow Designer) and create a new Flow. In the trigger selection screen:

• Select Application as the trigger category
• Select REST as the trigger type
• Give the flow a clear name — for example, "Create Incident from External System"

Once you select the REST trigger, Flow Designer will prompt you to define the input variables. These are the parameters the external system will send in the POST payload. Define one input variable for each piece of data you need:

• Name: short_description, Type: String
• Name: caller_id, Type: String
• Name: category, Type: String
• Name: priority, Type: Integer

Input variables defined here become data pills available throughout the flow. They map directly to the JSON fields in the incoming POST body.

Step 2 — Build the Flow Actions

With the trigger configured, build the flow actions as you normally would. For a create-incident use case, the flow actions are straightforward:

• Action: Create Record — Table: Incident. Map the input variable data pills to the incident fields (short_description, caller_id, category, priority)
• Action: Look Up Record — optional, to retrieve additional data before creating the record
• Action: Send Notification — optional, notify the assignment group

Add error handling at each step. Use the Error Handler spoke to catch failures and log them or send an alert. A flow triggered by an external system that fails silently is worse than a flow that fails loudly — the calling system may assume success and never retry.

Step 3 — Get the Endpoint URL

Save and activate the flow. Once active, ServiceNow generates a unique REST endpoint URL for the flow. To find it:

• Open the flow in Flow Designer
• Click the trigger step at the top
• The endpoint URL is displayed in the trigger configuration panel

The URL format is:

POST https://<instance>.service-now.com/api/sn_fd/flow/<flow_sys_id>/run

This URL is stable — it does not change when you update the flow. Share it with the external system team and document it in your integration specification.

Step 4 — Configure Authentication

The REST API trigger endpoint requires authentication. The external system must authenticate with ServiceNow before the endpoint accepts requests. The recommended approach is OAuth 2.0 Client Credentials.

In ServiceNow, navigate to System OAuth > Application Registry and create an OAuth API endpoint for external clients. This generates a client_id and client_secret for the external system. The external system requests a token from /oauth_token.do using those credentials, then includes the Bearer token in every call to the flow endpoint.

Create a dedicated service account for the integration with only the roles needed to trigger flows and create the target records. Never use an admin account for external integrations.

Step 5 — Structure the POST Payload

The external system calls the endpoint with a JSON body. The payload structure maps directly to the input variables you defined in Step 1:

POST /api/sn_fd/flow/<flow_sys_id>/run
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "inputs": {
    "short_description": "Database connection timeout on prod-db-01",
    "caller_id": "john.smith@example.com",
    "category": "database",
    "priority": 1
  }
}

The response from ServiceNow is immediate and returns HTTP 202 Accepted with a execution ID:

{
  "executionId": "a1b2c3d4e5f6...",
  "status": "RUNNING"
}

The 202 response means ServiceNow has accepted the request and the flow is running asynchronously. The calling system does not need to wait for the flow to complete. Store the executionId if you need to query the flow's outcome later.

Step 6 — Handle the Async Pattern Correctly

The REST API trigger runs flows asynchronously. This is by design — flows can take seconds or minutes to complete, and the calling system should not hold an open connection waiting. The calling system receives 202 immediately and continues its own execution.

If the external system needs to know the outcome of the flow — for example, to get the incident number that was created — there are two patterns:

Pattern 1 — Polling. The external system stores the executionId from the 202 response and polls a status endpoint periodically until the flow completes:

GET /api/sn_fd/flow/execution/<executionId>/status
Authorization: Bearer <access_token>

Pattern 2 — Callback webhook. Add an outbound REST step at the end of your flow that POSTs the result back to a webhook endpoint on the calling system. This is more efficient — the calling system does not poll, it just receives the result when the flow completes.

For simple fire-and-forget integrations (create record, send notification, close ticket), the async pattern requires no additional work. The calling system does not need the outcome, and 202 is sufficient confirmation.

Step 7 — Monitor with Execution Details

Every invocation of a REST-triggered flow is logged in Flow Designer's execution history. Navigate to Flow Designer > Executions and filter by your flow name. Each execution record shows:

• Trigger time and completion time
• The exact input values received in the POST payload
• Output of every action step
• Any errors, with the full error message and the step that failed

This is the most important operational tool for a REST-triggered flow. When the external system team reports "the integration is not working," open Execution Details before touching any code. The issue is usually visible immediately — a missing input field, an authentication failure, a required field that is null.

Common Issues and How to Fix Them

401 Unauthorized on the endpoint. The Bearer token has expired (default expiry is 1800 seconds) or the OAuth client credentials are incorrect. The external system needs to request a new token and retry. Implement automatic token refresh in the calling system.

Flow triggered but input variables are empty. The JSON payload keys in the external system's request do not match the input variable names defined in the flow trigger. Variable names are case-sensitive. Check the exact names in Flow Designer against the exact keys in the payload.

Flow creates records with wrong field values. The data pill mapping in the Create Record action is incorrect. Open the action in Flow Designer and verify each field is mapped to the correct input variable data pill, not a hardcoded value.

Flow runs but external system gets 404. The endpoint URL includes the flow sys_id. Verify the sys_id in the URL matches the actual sys_id of the active flow version. If you deleted and recreated the flow, the sys_id will have changed.

When to Use Scripted REST API Instead

The REST API trigger covers most use cases. Use a Scripted REST API instead when:

• You need to transform or validate the payload before starting the flow
• The external system cannot match the input variable structure the trigger expects
• You need to return a synchronous response with data from the flow (sys_id, record number)
• You need to trigger different flows conditionally based on payload content

For all other cases, the REST API trigger is faster to build, easier to maintain, and requires no custom scripting.