# Configure Lambda HTTP access

From CLI 1.0.70, a compatible ASP.NET Lambda service can declare its HTTP endpoint in stage configuration. Kanject creates a companion REST API stack, routes it through the function’s `live` alias, and requires a successful health check before recording the release.

**You'll learn**

- Choose managed, external, or pending HTTP ownership for a stage
- Configure the authentication contract and a safe health endpoint
- Understand which checks prove a deployment and how to resume a stopped operation

## Check the supported shape

- Exactly one `lambda-aspnetcore` entry, managed .NET ZIP packaging, and `arm64`.
- A public, buffered `api-gateway-rest` endpoint in one region.
- No stage `targets[]`, custom `api.domain`, or coupled static site.
- Matching ASP.NET Lambda REST-v1 hosting and serialization in the application.

HTTP API, Function URL, private access, streaming, Native AOT, and multi-entry managed enrollment are outside this release. Keep template/external ownership for those configurations. Existing template-owned services continue on their existing deployment path.

## Choose who owns the endpoint

### `kanject aws configure http`

Plan and save HTTP settings for an existing enrolled stage. With no explicit choices in a terminal, open the guided flow. Configuration does not create cloud resources.

Flags:

- `--env <STAGE>` — required existing stage; --stage is an alias
- `--entry <ID>` — entry ID; inferred only when unambiguous
- `--kind api-gateway-rest` — select managed REST access
- `--auth application|anonymous` — declare where authentication is enforced
- `--verification-path /health` — required safe relative GET path
- `--mode managed|external|pending` — choose endpoint ownership
- `--dry-run` — validate and preview without writing files
- `--non-interactive` — never prompt; supply the choices explicitly
- `--json` — return plan messages or coded errors without prompts
- `--cwd <DIR>` — service root override

`managed` lets Kanject reconcile the endpoint. `external` preserves template/external ownership. `pending` records that setup is unfinished and blocks deployment before building. External and pending modes cannot carry managed access flags, and switching ownership does not delete an existing managed stack or adopt an existing endpoint.

```bash
# Run from the existing service root; preview the local changes first
kanject aws configure http --env dev --entry api --non-interactive \
  --kind api-gateway-rest --auth application --verification-path /health --dry-run

# Save the same configuration, then check and deploy it
kanject aws configure http --env dev --entry api --non-interactive \
  --kind api-gateway-rest --auth application --verification-path /health
kanject doctor --env dev
kanject aws deploy --env dev
```

Setup writes `httpHost` on the manifest entry (`aspnetcore-lambda` / `rest-v1`) and the stage’s `http` map, keyed by entry ID. Managed enrollment can upgrade schema v1 to v2. Existing authentication and health-path choices may be reused; new automated setup must provide them.

```json
{
  "http": {
    "api": {
      "mode": "managed",
      "kind": "api-gateway-rest",
      "exposure": "public",
      "responseMode": "buffered",
      "auth": { "kind": "application" },
      "verification": {
        "required": true,
        "path": "/health",
        "expectedStatus": 200
      }
    }
  }
}
```

> **Application authentication is an explicit contract:** `--auth application` does not create gateway authentication. Requests reach the application, which must enforce its own policy. The health probe proves only the declared health response; use a configured protected probe to verify unauthenticated rejection and authenticated success. Select `anonymous` only when anonymous application access is intended.

## Enroll during initialization

```bash
# Enroll an existing compatible project with managed HTTP
kanject init --yes --service acme --stages dev --schema 2 \
  --http-kind api-gateway-rest --http-auth application \
  --http-verification-path /health
```

Run `init` only when enrolling an existing project. A service already initialized by `kanject new` should use `aws configure http`. Interactive enrollment can also keep external ownership or defer setup; non-interactive initialization without HTTP flags keeps template ownership.

## Verify and recover

Deployment rechecks capability and AWS ownership, reconciles the companion stack against the recorded `live` alias, then runs the required GET probe. Define the path in your application; `/health` is an example, not a route the gateway creates. A failed required probe prevents a successful release record.

An interrupted operation records its phase and handles. Rerun unchanged inputs to resume. If source or settings changed, `KANCLI680` requires inspecting the serving revision and recorded handles before an explicit `kanject aws deploy --env dev --restart-http`. Restart does not bypass ownership or migration checks. Rollback uses the recorded HTTP evidence and re-verifies the endpoint.

See [diagnostics KANCLI670–681](https://www.kanject.com/docs/cli-diagnostics/#kancli670) for configuration, ownership, reconciliation, verification, and recovery failures.

**Recap**

- Managed HTTP currently means one managed .NET arm64 Lambda behind a public, buffered REST API.
- Configuration writes local declarations; deployment reconciles AWS resources and verifies the declared endpoint.
- Application authentication remains the application’s responsibility, and interrupted operations resume from recorded state.

---
_Source: https://www.kanject.com/docs/cli-http/ · Kanject Docs_