Zapier bundle.inputData structure differs from inputFields configuration - nested properties appear duplicated

Other Questions Zapier
1

I’m working on a Zapier integration with an “addUser” action. I’ve set up the inputFields array to define what users see in the Zapier interface, including some nested field structures.

The UI renders correctly, but when I test the zap, the data format in bundle.inputData doesn’t match my inputFields structure. The nested properties seem to be duplicated in two different locations.

Here’s my configuration:

module.exports = {
  key: 'user',
  noun: 'User',
  create: {
    display: {
      label: 'Add User',
      description: 'Adds a new user record.'
    },
    operation: {
      inputFields: [
        {key: 'name', required: true},
        {key: 'surname', required: true},
        {key: 'email', required: false},
        {key: 'phone', required: false},
        {key: 'department', required: false},
        { 
          key: 'experience', children: [
            {key: 'company', required: false},
            {key: 'position', required: false},
            {key: 'duration', required: false, label: 'Years of Experience'},
            {key: 'level', required: false},
            {key: 'startYear', required: false, type: 'datetime' },
            {key: 'endYear', required: false, type: 'datetime' },
          ] 
        }
      ],
      perform: addUser
    },
  },

  sample: {
    id: 1,
    name: 'Sample name',
    surname: 'Sample surname'
  },

  outputFields: [
    {key: 'id', label: 'ID'},
    {key: 'name', label: 'Name'},
    {key: 'surname', label: 'Surname'},
  ]
};

When I log bundle.inputData in the addUser function, the nested fields appear in two places:

== Log
inputData: { startYear: '10/03/2018',
  company: 'XYZ Corp',
  endYear: '12/03/2019',
  position: 'Developer',
  name: 'John',
  level: 'Senior',
  surname: 'Smith',
  duration: '2 years',
  experience:
   [ { startYear: '2018-03-10T00:00:00+00:00',
       company: 'XYZ Corp',
       endYear: '2019-03-12T00:00:00+00:00',
       position: 'Developer',
       level: 'Senior',
       duration: '2 years' } ],
  email: '[email protected]' }

I expected bundle.inputData to match the structure I defined in inputFields. How can I make the input data format consistent with my field configuration?

2

I hit this exact problem building my first Zapier integration last year. The duplication happens because Zapier’s CLI flattens nested fields to the root level but also keeps your structured format. This all goes down during input processing, before your perform function even sees the data. In your addUser function, just use bundle.inputData.experience array and ignore the flat properties like bundle.inputData.company or bundle.inputData.startYear. The flat structure’s there for legacy reasons and easier field mapping sometimes. Here’s what tripped me up - the nested array always has objects even if users only fill out one experience section. So bundle.inputData.experience[0] gets you the first entry. Just watch out for empty arrays if users skip those optional fields completely.

3

yeah, that’s just how zapier works. they flatten nested fields to make it easier to access them but still keep the structured version. just stick to bundle.inputData.experience and ignore the flat props at the root. it’s all about backward compatibility.

4

This is normal Zapier behavior. The CLI automatically creates both flat and nested structures for fields with children properties. You get flat properties for backward compatibility and easier access, plus the nested array that matches your inputFields setup. Use the nested bundle.inputData.experience array in your addUser function, not the flat properties. The nested structure is the official one that matches your field definition. Just ignore the flat properties like bundle.inputData.company, bundle.inputData.position, etc. To access experience data, use bundle.inputData.experience[0].company or loop through the array if you’re expecting multiple entries. Zapier generates both formats automatically, but stick with the nested structure for your integration logic.