Skip to main content
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

FieldTypeRequiredDefaultDescription
orgstringYes—Organization the gateway belongs to. Gateways are always org-scoped.
typestringYes—Gateway integration type. servicenow is the default; runner is for sandbox benchmarking; custom-built types are configured by 2501 ahead of time.
activebooleanNotrueToggle the gateway on or off without deleting it.
inbound_override_enabledbooleanNofalseTurn the inbound prompt override on. When off, the gateway uses its built-in default routing. The inbound prompt text is the MDX body.
outbound_promptstringNo—The outbound prompt — what 2501 writes back to the ticket when a job finishes (status, comment, escalation). See Prompting a Gateway.
outbound_override_enabledbooleanNofalseTurn the outbound prompt override on. When off, the gateway uses its built-in default mapping (e.g. a successful incident is resolved).
metadataobjectNo{}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)

KeyTypeDescription
servicenow_escalation_group_idstringsys_user_group sys_id to escalate unresolved tickets to. See Escalation Groups.
dedup_window_minutesintegerHow far back to look when deduplicating incoming incidents. Default 30. Set -1 to disable deduplication.
assignment_group_filterstringOnly act on tickets assigned to this group
environment_filterstringOnly act on tickets matching this environment label
skip_tls_verifybooleanSkip 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.