Gateway

Subdirectory: gateways/ · Body: the inbound prompt A gateway has two prompts, each an optional override you toggle on (see Prompting a Gateway):

The inbound prompt — routing and scope — comes from the MDX body.
The outbound prompt — what 2501 writes back when a job finishes — is set in frontmatter via outbound_prompt.

Each side is independent: you can enable one, both, or neither. When a side’s override is off, the gateway uses its built-in default handling for that side. Enabling a side in Command Center seeds a default template you can edit as a starting point.

Frontmatter

Field	Type	Required	Default	Description
`org`	string	Yes	—	Organization the gateway belongs to. Gateways are always org-scoped.
`type`	string	Yes	—	Gateway integration type. `servicenow` is the default; `runner` is for sandbox benchmarking; custom-built types are configured by 2501 ahead of time.
`active`	boolean	No	`true`	Toggle the gateway on or off without deleting it.
`inbound_override_enabled`	boolean	No	`false`	Turn the inbound prompt override on. When off, the gateway uses its built-in default routing. The inbound prompt text is the MDX body.
`outbound_prompt`	string	No	—	The outbound prompt — what 2501 writes back to the ticket when a job finishes (status, comment, escalation). See Prompting a Gateway.
`outbound_override_enabled`	boolean	No	`false`	Turn the outbound prompt override on. When off, the gateway uses its built-in default mapping (e.g. a successful incident is resolved).
`metadata`	object	No	`{}`	Gateway-type-specific configuration — see Metadata by type.

Fields NOT supported

id, tenant_id, org_id, created_at, updated_at — system-set
inbound prompt as a frontmatter field — it comes from the MDX body, not frontmatter (use inbound_override_enabled to toggle the override)
Webhook registrations — managed separately via 2501 infra webhook

Metadata by type

ServiceNow (`type: servicenow`)

Key	Type	Description
`servicenow_escalation_group_id`	string	`sys_user_group` sys_id to escalate unresolved tickets to. See Escalation Groups.
`dedup_window_minutes`	integer	How far back to look when deduplicating incoming incidents. Default `30`. Set `-1` to disable deduplication.
`assignment_group_filter`	string	Only act on tickets assigned to this group
`environment_filter`	string	Only act on tickets matching this environment label
`skip_tls_verify`	boolean	Skip TLS certificate verification when connecting to the ServiceNow instance. Enables connectivity to on-premises instances with self-signed certificates. Default `false`.

Runner (`type: runner`)

No required metadata. Used only for sandbox benchmarking via 2501 runner start.

Custom-built types

If your tenant has a custom gateway, the metadata schema is provided by your account team. The CLI does not validate custom metadata keys — anything you put under metadata: round-trips verbatim.

Example

gateways/servicenow.mdx

---
org: platform-team
type: servicenow
active: true
inbound_override_enabled: true
outbound_override_enabled: true
outbound_prompt: |
  On full success, set the incident to Resolved with close code
  'Solved (Permanently)' and post a brief public comment in plain language.
  On failure, leave it open, post an internal work note with the technical
  details, and reassign it to the 'Platform On-Call' group.
metadata:
  servicenow_escalation_group_id: a1b2c3d4e5f6a7b8c9d0
  dedup_window_minutes: 30
---
Only take tickets that target the web and database hosts. Skip tickets about
network appliances and end-user workstations.

For master-slave pairs (nyc1-app-jvm-01 and nyc1-app-jvm-02), always create
the task on both hosts in parallel and treat the ticket as resolved only
when both succeed.

Gotchas

type is fixed. Adding a new gateway type (a vendor we don’t have an integration for) requires a 2501 release — contact your account team. Configuring an existing type is pure MDX.
Webhook records are separate. A gateway’s MDX file doesn’t manage its webhooks. Recreate webhooks with 2501 infra webhook create --gateway-id ... (see Webhooks).
One gateway per org per type. ServiceNow + Runner in the same org is fine; two ServiceNow gateways in the same org is not.

CLI

Deploy

Configure

Frontmatter

Fields NOT supported

Metadata by type

ServiceNow (`type: servicenow`)

Runner (`type: runner`)

Custom-built types

Example

Gotchas

​Frontmatter

​Fields NOT supported

​Metadata by type

​ServiceNow (type: servicenow)

​Runner (type: runner)

​Custom-built types

​Example

​Gotchas

Frontmatter

Fields NOT supported

Metadata by type

ServiceNow (`type: servicenow`)

Runner (`type: runner`)

Custom-built types

Example

Gotchas