---
id: types-import
title: "Import types"
summary: "Create flow types from a JSON sample, a YAML sample, or a JSON Schema / OpenAPI document - how values, names, formats, enums and nesting are mapped."
audience: user
keywords: "import, json sample, yaml sample, json schema, openapi, swagger, types, schema, format, date-time, uuid, enum"
---
# Import types

When the data already exists somewhere, don't build its type by hand. Paste a sample message or the other system's
schema, and the type editor creates the types for you.

In the type editor, open the **Import** menu and choose:

| Menu item | Paste |
|---|---|
| **From JSON sample** | A JSON object, or an array of objects. |
| **From YAML sample** | The same data as YAML. |
| **From JSON Schema** | A JSON Schema, or an OpenAPI or Swagger document, as JSON or YAML. |

Paste the text into **Paste source here** and click **Import**. The new types go into the flow's namespace; a type
whose name already exists is kept as it is. Anything the importer had to simplify is listed under
**Imported with warnings**.

## From a sample

Every JSON object becomes a type. Nested objects, and objects inside arrays, become types named after their
property; arrays become **List** fields.

```json
{
  "orderId": 10045,
  "customer": { "name": "Ana Horvat", "email": "ana@example.com" },
  "lines": [ { "sku": "A-100", "quantity": 2, "price": 19.90 } ],
  "express": true
}
```

gives the types `NewType` (the root), `Customer` and `Lines`. Rename the root after the import.

| JSON value | Field type |
|---|---|
| whole number | `Int64`, nullable |
| other number | `Decimal`, nullable |
| `true` / `false` | `Boolean`, nullable |
| text, `null` or mixed values | `String` |
| object | a new type |
| array | a **List** of the item type |

Field names are turned into C# names (`orderId` becomes `OrderId`) and the original JSON name is kept as the
**Serialization name**, so the type reads and writes the same JSON. Paste an array of several objects to merge their
fields into one type. Samples don't carry formats: change dates and identifiers from `String` to `DateTimeOffset` or
`Guid` after the import when you need them typed.

YAML samples work the same way.

## From a JSON Schema or OpenAPI document

The importer reads JSON Schema 2020-12 and earlier drafts. From an OpenAPI or Swagger document it imports every schema
under `components/schemas` (or `definitions`).

| Schema | Field type |
|---|---|
| `string`, `format: date-time` | `DateTimeOffset` |
| `string`, `format: date` | `DateOnly` |
| `string`, `format: uuid` | `Guid` |
| `string`, `format: byte` or base64 content | byte array |
| `string` | `String` |
| `integer`, `format: int32` | `Int32` |
| `integer`, `format: uint64` | `UInt64` |
| `integer` | `Int64` |
| `number`, `format: float` / `double` | `Single` / `Double` |
| `number` | `Decimal` |
| `object` with `additionalProperties` | **Dictionary** |
| `object`, `allOf` | a type |
| integer `enum` | an enum, member names from `x-enum-varnames` or `x-enumNames` |
| string `enum` | `String` |

Properties that are not `required` become nullable. Defaults and descriptions are taken over. Constructs a C# type
can't express directly - `oneOf` / `anyOf` over different types, tuples, references to other documents - become fields
that hold any JSON value, with a warning.

A JSON Schema exported from Viaducta imports back into exactly the same types, so you can move a contract between
installations or keep it in version control.