---
schema_version: "1"
id: 0af52e2bed24f68cd600de63ea51955a5f0aa48fd4e64acc836d501bd554f808
title: Requirements for Ingestion API Schema File
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/data-cloud/data-cloud-int/guides/c360-a-ingestion-api-schema-req.md
canonical_url: https://developer.salesforce.com/docs/data/data-cloud-int/guide/c360-a-ingestion-api-schema-req.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: 269c9aeb1bd36241b3d9267cddda90d1ff7da06954b6f841980892c60e741782
products:
  - Data 360 Integration Guide
  - Data 360 Developer Documentation
---
# Requirements for Ingestion API Schema File

Use the Ingestion API Schema File requirements to successfully build a file to bring data into Data 360.

To create an ingestion API source in Data 360, the schema file you upload must meet specific requirements.

- Uploaded schemas have to be in valid OpenAPI format with a .yml or .yaml extension. OpenAPI version 3.0.x is supported
- Objects can’t have nested objects.
- Each schema must have at least 1 object. Each object must have at least 1 field.
- Only one Data Stream can be created per object per connection.
- Objects can’t have more than 1000 fields.
- Objects can’t be longer than 79 characters.
- Field names can’t exceed 39 characters.
- Object names must contain only a-z, A-Z, 0-9, `_`, and `-`. Unicode characters aren't supported.
- Objects can’t be deleted from the schema after they are uploaded.
- Field names must contain only a-z, A-Z, 0-9, `_`, and `-`. Unicode characters aren't supported.
- Field names can’t be any of these reserved words: date_id, location_id, dat_account_currency, dat_exchange_rate, pacing_period, pacing_end_date, row_count, version. Field names can’t contain string \_\_.
- A field once added to an object’s schema can't be removed. Similarly, an object once added to the top-level schema associated with an active connection can't be removed.

- Fields meet the type and format requirements:

  - For boolean type

    ```nolang
    booleanField:
                type: boolean

    ```

  - For date type

    ```nolang
    dateField:
                type: string
                format: date

    ```

  - For datetime type

    ```nolang
    dateTimeField:
                type: string
                format: date-time

    ```

    **note:** Once the data is ingested, the date and time values are adjusted as per the time zone configured in your org.

  - For email type

    ```nolang
    emailField:
                type: string
                format: email

    ```

  - For number type

    ```nolang
    numberField:
                type: number

    ```

  - For phone type

    ```nolang
    phoneField:
                type: string
                format: phone

    ```

  - For percent type

    ```nolang
    percentField:
                type: string
                format: percent

    ```

  - For text type

    ```nolang
    textField:
                type: string

    ```

  - For URL type

    ```nolang
    urlField:
                type: string
                format: url

    ```

- Object names can’t be duplicated, case insensitive.
- Objects can’t have duplicate field names, case insensitive.
- Date data type fields in your payloads must be valid calendar dates conforming to ISO 8601 format `yyyy-MM-dd`.
- DateTime data type fields in your payloads must be in ISO 8601 UTC Zulu with format `yyyy-MM-dd'T'HH:mm:ss.SSS'Z'`.

When updating your schema, be aware:

- Existing field data types can’t be changed.
- Upon updating an object, all of the existing fields for that object must be present.
- Your updated schema file only includes changed objects, so you don’t have to provide a comprehensive list of objects each time.
- A datetime field must be present for objects that are intended for**engagement**category. Objects of category **profile** or **other** don’t impose this same requirement.

**note:** If you send a payload using field API names instead of the schema-defined field names, the system can't recognize the fields or their values. As a result, the data stream displays a single row with blank columns. Since the payload has no valid fields, the ingestion process interprets each call as an upsert to the same record, ultimately populating that record with only blank values.

## Example

Ingestion API schemas have set requirements. Review the schema requirements before ingestion.

Schema example:

```yaml
openapi: 3.0.3
components:
  schemas:
    Order:
      type: object
      properties:
        contact_name:
          type: string
        created_date:
          type: string
          format: date-time
        id:
          type: string
        total:
          type: number
        shipAddress:
          type: string
        taxExempt:
          type: string
        tax_rate:
          type: number
        my_email:
          type: string
          format: email
        my_phone:
          type: string
          format: phone
        my_url:
          type: string
          format: url
        my_percent:
          type: string
          format: percent
        is_new:
          type: boolean
        modifie_date:
          type: string
          format: date-time
    OrderItem:
      type: object
      properties:
        cost:
          type: number
        createdDate:
          type: string
          format: date-time
        quantity:
          type: number
        name:
          type: string
        orderId:
          type: string
        itemNumber:
          type: number
    SalesCustomer:
      type: object
      properties:
        address:
          type: string
        age:
          type: number
        city:
          type: string
        country:
          type: string
        modifiedDate:
          type: string
          format: date-time
        firstName:
          type: string
        gender:
          type: string
        id:
          type: string
        lastName:
          type: string
        createdDate:
          type: string
          format: date-time
```
