How can I check that a JSON value is an object with the keys I need?

Check document.RootElement.ValueKind before looking up any properties. In System.Text.Json, ValueKind identifies the kind of the current JSON value; comparing the root with JsonValueKind.Object tells you whether the top level is an object. [S1]

For example, assume your application requires the keys name and email. Those are illustrative schema choices, not requirements imposed by JSON. If the root is an array, string, number, or another non-object value, report the root-type problem and stop that validation path. Do not call TryGetProperty on it: that method is for an object, and calling it on another kind can throw InvalidOperationException. [S2]

Call TryGetProperty once for every required name, collect the names for which it returns false, and report that collection. It both searches the current object and indicates whether the named property exists. [S2] The example below returns a message for a wrong root kind or a list of missing keys:

using System;
using System.Collections.Generic;
using System.Text.Json;

static string? Validate(JsonElement root)
{
    if (root.ValueKind != JsonValueKind.Object)
        return $"Expected a JSON object; got {root.ValueKind}.";

    string[] required = { "name", "email" };
    var missing = new List<string>();

    foreach (string key in required)
    {
        if (!root.TryGetProperty(key, out _))
            missing.Add(key);
    }

    return missing.Count == 0
        ? null
        : $"Missing required keys: {string.Join(", ", missing)}.";
}

Here, null means the two checks passed; adapt that return convention to your application. The root-kind check happens first, so the property checks run only on an object.

A key with a JSON null value is present: TryGetProperty checks whether the property exists, not whether its value is non-null, correctly typed, or useful. [S2] If null is not allowed, add a separate value check after the key is found. Similarly, the documented string overload matches property names using ordinal, case-sensitive comparison, so Name does not satisfy a required key named name. [S2]

The example therefore validates presence only. It does not establish that name is a string, that email is non-empty, or that either value meets your application's rules. Those checks need a separate schema-specific step.

Try a non-object root, an object with all required keys, and an object missing one or both. For example, with the assumed keys name and email, [] should produce the wrong-root message, while { "name": "Ada" } should report email as missing. An object containing both keys with null values passes this particular presence check; that result is expected, not proof the values are acceptable.

Keep the error distinction visible in your application: a wrong root is a type problem, while missing names are property-presence problems. The API documentation supports these .NET checks; it does not define your required keys or value rules. Decide those from your own input contract.