Short answer: there isn’t a single, universal “response schema” for the after-registration webhook. What you return depends on what you want the webhook to do. The docs define three relevant behaviors: - Do nothing special (fire-and-forget): Return 200 or 204; if you configured response.ignore: true or did not enable parsing, the flow continues and the response body is ignored (no specific schema required) ([Webhook guide – Define HTTP request](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#define-http-request)). - Interrupt or allow the flow (flow-interrupting): Enable parsing and return an HTTP status. 1xx–3xx lets the flow continue; 4xx/5xx interrupts and you may return a payload with messages pointing to fields, e.g.:

{
  "messages": [
    {
      "instance_ptr": "#/traits/foo/bar",
      "messages": [
        {
          "id": 123,
          "text": "field must be longer than 12 characters",
          "type": "error",
          "context": {
            "value": "short value"
          }
        }
      ]
    }
  ]
}

This requires config.response.parse: true ([Webhook guide – Flow-interrupting webhooks](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#flow-interrupting-webhooks)). - Modify the identity before it’s saved: Enable parsing and return 200 with a JSON body containing identity fields to replace. Supported keys: - identity (entire identity object fields you set will replace existing ones) - identity.traits (replaces the whole traits object) - identity.metadata_public / identity.metadata_admin (each replaces its whole object) - identity.verifiable_addresses and identity.recovery_addresses (must be consistent with traits) Example:

{
  "identity": {
    "traits": {
      "email": "<mailto:joe@example.org|joe@example.org>",
      "another_value": "example"
    }
  }
}

Requires config.response.parse: true; only available in registration and settings flows ([Webhook guide – Modify identities](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#modify-identities)). Notes: - The session action (auto sign-in) modifies the HTTP response and must run last; otherwise subsequent hooks won’t execute ([Actions – Sign in after registration](https://www.ory.sh/docs/actions/session)). This affects hook ordering but not the webhook response schema itself. - For native clients, if the session action runs, Ory’s own response includes session and session_token; this is unrelated to your webhook’s response body schema ([Registration – API clients](https://www.ory.sh/docs/kratos/self-service/flows/user-registration#api-clients), [Actions – session](https://www.ory.sh/docs/actions/session)).

Short answer: No. The knowledge sources do not provide a formal JSON Schema or OpenAPI definition for webhook responses when response.parse: true. The docs only show examples and describe behavior: - Flow-interrupting webhooks: HTTP 1xx–3xx continue, 4xx/5xx interrupt. If interrupting, you may return a messages payload shaped like the example with instance_ptr and messages, but no formal schema is published (only examples) ([Flow-interrupting webhooks](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#flow-interrupting-webhooks)). - Modifying identities: Return 200 with a JSON body keyed by identity, identity.traits, identity.metadata_public, identity.metadata_admin, verifiable_addresses, recovery_addresses. Replacement semantics are documented, but again, no formal JSON Schema/OpenAPI is provided—only examples and rules ([Modify identities](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#modify-identities)). If you need a detailed, stable schema, the docs suggest opening a support ticket for event schemas; by analogy, you may also reach out for webhook schema guarantees ([Live event streams – stability note](https://www.ory.sh/docs/actions/live-events)).

A message from kapa.ai

I’m sorry, but there is no published JSON Schema or OpenAPI definition for webhook responses when response.parse: true. The docs describe behavior and provide examples only: - Flow-interrupting responses: parsing enabled; 1xx–3xx continue, 4xx/5xx interrupt. Optional messages structure is shown as an example, not a formal schema ([Flow‑interrupting webhooks](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#flow-interrupting-webhooks)). - Identity modification responses: parsing enabled; return 200 with a body containing identity, identity.traits, identity.metadata_public, identity.metadata_admin, verifiable_addresses, recovery_addresses; replacement semantics are documented, but no formal schema is provided ([Modify identities](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#modify-identities)). If you need a stable, formal spec, you’ll need to reach out to Ory support to discuss guarantees similar to how event attribute schemas are handled ([Live event streams](https://www.ory.sh/docs/actions/live-events)).