Skip to main content

Hello,

I’m creating a Zapier integration and I have a field like this in my API requirements:

{"records":"
  {"field1":"val1","field2":"val2"},
  {"field3":"val3","field4":"val4"}
]}

But I guess there isn’t a way of adding multiple dictionaries on Input Designer. I tried handling it with CLI but that didn’t work for me either.

So far, I used CLI to create a line item with {link:true}. Fields in Records Line Item are populated dynamically as user adds fields from the input above. I just need records to accept a set of fields not just one.

 

@tolgaouzz 

Sorry we missed this!
Just checking in to see if you still need help with this? 

Hey! 

I do actually, I managed to find a way around this by making this field an array of strings and have the user pass JSON objects as strings, then parsing them while sending. But if there’s a native way to do this, I’d love to learn about it

@tolgaouzz  You may know this, or this may be the missing link here, just throwing it out.  “Line items” in Zapier expect to consume an array from the trigger/subsequent actions step.  You might argue the editor doesn’t necessarily make it self-evident that a) it expects and array to be provided; and b) while the user creates a single, representative mapping of a single item, when the Zap runs your Zapier integration will consume an entire array of those objects and send them to your API.  

So in your example the Records line item, should have two children field1 and field2.  Your user would map val1 and val1 to those in the editor… but when the Zap was turned on and it was passed this array, the full array would get passed to your API.  Also your second object in the array has a different set of field names, and that’s probably not what you want - each object in the array should have the same definition.  

I’m wondering if the workaround you’re having users do is actually necessary. I suspect it’s not and you can provide them with a way cleaner experience by using plain line items.

Hello @Zane , thanks for the answer. Even though i looked line items up in the cli & editor documentations i didn’t realize this was the case for line items. But I have 2 questions regarding this use case:

1-) What if we don’t have a trigger and user is needed to pass a standard set of line items to the action on every run. e.g.

s{“field1”:”bla”,”field2”:”bla2”},{“field1”:”bla3”,”field2”:”bla4”},...] 

2-) I know there’s an option to dynamically retrieve the keys for line items, in my case line item object’s keys will always be one of the strings from “Fields” section in the given screenshot.For example we have “field1”,”field2”,”field3” as our Fields in the screenshot, then all the line items may have these attributes. They cant have anything else than these keys BUT they might not have one of them as well. e.g. a line item can be

{
  "field1":"bla1"
}

and this would be a valid line item. So in this case the question is, does every line item need to have a pre-defined set of fields or is it okay to have some missing fields as long as they dont have anything not defined.

 

Thanks!

Terms & Conditions