Answer
If you can guarantee the JSON will always stay under roughly 4,000 characters, a single VARCHAR2-type custom field can hold the whole thing as-is. Beyond that size, you're constrained by custom fields not supporting a CLOB type (they're capped around that same 4,000-character limit), so a genuinely large or structurally complex JSON payload needs to be modeled into one or more Custom Logical Units that mirror the JSON's actual hierarchy, with related child records connected the way the JSON's own nesting flows — which isn't trivial when the JSON has variable-length arrays or objects nested inside other objects. This is exactly why JSON (and XML) payloads are so often instead stored as one large text blob and deserialized on demand by application code capable of handling that non-tabular structural complexity, rather than being force-fit into a flat relational shape up front.