For the complete documentation index, see llms.txt. This page is also available as Markdown.

Config Normalization: Legacy Keys

Understand how legacy aliases like `http` and `servicesBindings` are normalized before routing begins. The gateway automatically converts old field names to

Understand how legacy aliases like http and servicesBindings are normalized before routing begins. The gateway automatically converts old field names to their current equivalents during config parsing. This page documents every legacy alias so you can plan your migration from older config formats.

Last reviewed: 2026-03-06

When to use this

Use the config reference when you need to understand the shape, source, or validation behavior of the gateway JSON configuration. The config file is the single source of truth for all routing, auth, CORS, and integration behavior in the gateway.

Key concepts

  • The config schema (api-config.schema.json) defines every valid field, type, and default. Use it with your editor for autocompletion and validation before deploying.

  • Config can be loaded from three sources: a local JSON file bundled with the worker, a Cloudflare KV namespace, or the SAG_API_CONFIG_JSON environment variable. The gateway checks them in that order.

  • Strict mode rejects any config with unknown fields or type mismatches at startup, returning a 500 error. Compatibility mode logs warnings but allows the worker to start.

  • Legacy key normalization automatically converts old field names (like http to paths and servicesBindings to serviceBindings) so older configs continue to work during migration.

Repo-grounded example

{
  "serviceBindings": [
    { "alias": "hooks", "binding": "HOOKS" },
    { "alias": "target", "binding": "TARGET" }
  ],
  "paths": [
    {
      "method": "POST",
      "path": "/orders",
      "pre_process": { "binding": "hooks", "function": "before" },
      "integration": {
        "type": "service_binding",
        "binding": "target",
        "function": "run"
      }
    }
  ]
}

This snippet uses the current field names serviceBindings and paths. If your config uses the legacy aliases servicesBindings or http, the gateway normalizes them to these canonical names before processing routes.

Troubleshooting

  • If the worker starts but routes return 404, check which config source the gateway loaded -- add a health route to each source so you can identify which one is active.

  • If strict mode rejects your config, run the JSON against api-config.schema.json locally with a JSON schema validator to see the exact validation errors.

  • If legacy key normalization is not converting a field, confirm you are running a version of the gateway that supports that alias -- check the CHANGELOG for the normalization version.

  • If KV config changes are not reflected after updating, remember that Workers cache KV reads. Redeploy the worker or wait for the cache TTL to expire.

Last updated