> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Gateway

> MDX frontmatter reference for gateway resources

**Subdirectory:** `gateways/` · **Body:** the inbound prompt

A gateway has **two prompts**, each an optional override you toggle on (see [Prompting a Gateway](/0.8/prompting/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`](#frontmatter).

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](/0.8/prompting/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](#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`](/0.8/cli/infra)

## 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](/0.8/core-concepts/gateways#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

```mdx gateways/servicenow.mdx theme={null}
---
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](/0.8/configure/webhooks)).
* **One gateway per org per type.** ServiceNow + Runner in the same org is fine; two ServiceNow gateways in the same org is not.