Skill gap: serving inbound HTTP endpoints (POST) from a canister

Gap

We identified a gap in the current skill coverage: no skill documents how a canister
serves an inbound HTTP endpoint (e.g. a plain POST a client can curl). This is a
common need — webhooks, ingest/receiver APIs, bot endpoints, health checks — and today
an agent has to work it out from the HTTP gateway protocol.

Why the existing skills don't cover it

• https-outcalls — outbound HTTP only.
• certified-variables — Rust ic-http-certification, GET/response-certification oriented.
• static-site — shows the http_request candid shape only for asset serving.
• custom-domains — merely mentions "any canister implementing http_request".

The pattern that works

For a mutating endpoint: http_request (query) returns upgrade = opt true; the gateway
re-issues the call as http_request_update (update), which may mutate state. Update
responses do not require query certification. Read side (GET) needs the certified-response
path instead.

For discussion — where should this live?

• A new skill (e.g. canister-http-endpoints, inbound — parallel to https-outcalls)?
• Or extend an existing skill?
• Motoko-only, or Motoko + Rust in one place?

Filing for discussion on placement before anyone writes content.

Review the existing https-outcalls, certified-variables, static-site, and custom-domains skills alongside the HTTP gateway protocol. Determine whether inbound POST endpoints need a new skill or an extension, and whether the content should cover Motoko, Rust, or both; done means the placement and scope are agreed before content is written.