JSON Schema for Parse JSON

What Parse JSON needs

The Parse JSON data operation and the When a HTTP request is received trigger both take a schema that describes the payload. The designer uses it for two jobs: to emit typed dynamic-content tokens for every property, and to validate the shape of the content at run time. The schema is a JSON Schema document in the draft-4-era vocabulary Logic Apps uses — a tree of nodes built from type, properties, items, and required.

Anatomy of a schema

Every schema is a tree of nodes. Each node declares a type; container nodes then describe their children — an object node carries a properties map, an array node carries an items schema. The root is almost always an object.

{
  "type": "object",
  "properties": {
    "status": { "type": "string" },
    "orders": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": { "type": "string" },
          "total": { "type": "number" }
        },
        "required": [ "id" ]
      }
    }
  },
  "required": [ "status" ]
}

Types: JSON value → schema type → token

Each JSON value maps to one schema type, which in turn decides the kind of dynamic-content token you get downstream.

Nullability: the #1 Parse JSON failure

By far the most common Parse JSON error is a field that is null or absent in real data but typed as a non-null required value in the schema. APIs routinely omit empty fields or send null — and a node typed "string" rejects null, while a required key that's missing fails the whole action.

// fails when "department" comes back null
"department": { "type": "string" }

// tolerates null
"department": { "type": [ "string", "null" ] }

• Allow null — change "type": "string" to "type": ["string", "null"] so a null value parses.
• Make it optional — remove the key from the node's required array so an absent field doesn't fail.
• Belt and braces — do both for any field you don't fully control; the action then never fails on that property.

Objects: properties & required

An object node lists each key under properties and (optionally) names mandatory keys in required. The generator's default — matching the designer — is to mark every key it saw as required, which is exactly why generated schemas are brittle.

{
  "type": "object",
  "properties": {
    "id":    { "type": "string" },
    "name":  { "type": "string" },
    "note":  { "type": [ "string", "null" ] }
  },
  "required": [ "id" ],
  "additionalProperties": false
}

Arrays: items, list vs. tuple

An array node describes its elements with items. A single schema under items means a homogeneous list — every element has the same shape. This is the form Power Automate generates and the one you almost always want.

"orders": {
  "type": "array",
  "items": {
    "type": "object",
    "properties": { "id": { "type": "string" } },
    "required": [ "id" ]
  }
}

"tags": {
  "type": "array",
  "items": { "type": "string" }
}

Validation keywords (and what Parse JSON enforces)

JSON Schema has a rich constraint vocabulary, but Parse JSON is a parser, not a validator. It enforces the structural keywords (type, required) and uses properties/items to build tokens; the rest are valid schema but effectively documentation here.

String formats & special values

The format keyword annotates strings (date-time, email, uri…). Parse JSON keeps them as plain string tokens — format doesn't change the type or get enforced, so you reshape values yourself with expressions.

Schema cookbook

Copy-paste starting points for the payloads you meet most. All are pre-relaxed where a field is commonly null — tighten required to taste.

Microsoft Graph collection (value array + nextLink)

{
  "type": "object",
  "properties": {
    "value": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id":          { "type": "string" },
          "displayName": { "type": "string" },
          "mail":        { "type": [ "string", "null" ] }
        },
        "required": [ "id" ]
      }
    },
    "@odata.nextLink": { "type": "string" }
  },
  "required": [ "value" ]
}

SharePoint / Dataverse rows (annotated OData)

{
  "type": "object",
  "properties": {
    "value": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "@odata.etag": { "type": "string" },
          "accountid":   { "type": "string" },
          "name":        { "type": "string" },
          "revenue":     { "type": [ "number", "null" ] }
        }
      }
    }
  }
}

Webhook trigger body (When a HTTP request is received)

{
  "type": "object",
  "properties": {
    "event":     { "type": "string" },
    "timestamp": { "type": "string" },
    "data": {
      "type": "object",
      "properties": {
        "id":     { "type": "string" },
        "amount": { "type": "number" }
      },
      "required": [ "id" ]
    }
  },
  "required": [ "event", "data" ]
}

A root-level array

{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "first": { "type": "string" },
      "last":  { "type": "string" }
    },
    "required": [ "first", "last" ]
  }
}

A dynamic key/value bag

{
  "type": "object",
  "additionalProperties": { "type": "string" }
}

An unpredictable sub-tree

"metadata": {}

Editing a generated schema

Treat the generated output as a first draft. A few quick edits turn a brittle schema into a robust one:

1. Relax null-prone fields — add "null" to the type of anything optional or sometimes-empty.
2. Trim `required` — keep only the keys you actually read downstream.
3. Fix integer → number — for any value that can be fractional.
4. Collapse volatile nodes to `{}` — sub-trees that change shape, or that you don't read.
5. Delete the noise — drop @odata.* and other keys you'll never reference to keep the token list clean.
6. Sample richly — paste a record where optional fields are populated, so the generator sees them at all.

Common gotchas

• Null on a non-null type — "Invalid type. Expected String but got Null" means add "null" to that node's type.
• Missing required key — a required field absent from the payload fails the action; remove it from required.
• integer vs. number — a decimal value fails an "integer" node; widen to "number".
• First-element sampling — the designer only reads array element [0]; optional keys on later items are missed (this generator merges them).
• Constraint keywords don't validate — enum, pattern, format, minimum are advisory in Parse JSON; validate critical rules yourself.
• Don't double-parse — connector actions usually return parsed objects already; only run Parse JSON / json() on raw strings.
• Quoted numbers are strings — "123" is a "string"; cast with int() / float() when you need maths.
• Secure the Request trigger — generating a schema from a sample doesn't authenticate callers; validate and gate the trigger (see the HTTP guide).