Hi @Katrina_Storm!

As long as you have some way to control the data that is being input (likely a form that asks for the table name and any fields they would like to add), you can always build the JSON object from those plain text responses with code.

The exact code you use is dependent on the form data being sent, whether it’s being sent as one long line of comma separate text or perhaps as an array of key/value pairs, and whether you’ve reformatted the field types (ie. singleLineText vs. checkbox, etc.).

How are you currently planning on collecting the responses from the user?

At the moment I’m trying to trigger it based on a new Google Sheets worksheet being created, to make a new table in Airtable to copy the data over. But I also want the App Extension to be generic enough that anyone on the team can use it without it requiring to be specifically linked to that trigger.

But I’m having trouble even getting it to make a new table at the moment. If I run a test on the Extension, it runs perfectly and I get the new table.

The body request in the set up is as follows:

{"description": "{{description}}", "fields": f {{fields}} ], "name": "{{name}}"}

But if I run the extension in a zap using the same fields JSON, I get an error

Status: 422

{"error":{"type":"INVALID_REQUEST_UNKNOWN","message":"Invalid request: parameter validation failed. Check your request data."}}

So if anyone can offer any pointers, that would be great!

I believe the reason you’re getting the error is that it’s expecting a list of JSON objects, so you should surround it in square brackets. So instead of

{"description": "Name of the apartment", "name": "Apartment Name", "type": "singleLineText"}

try

>{"description": "Name of the apartment", "name": "Apartment Name","type": "singleLineText"}]

Once we get that working, we can talk about how to bring the data in from Google Sheets.

The square brackets are prefilled in the App Extension body request, and works fine this way when I test it, just not live

Can you post a screenshot of the input data and any output data provided by the failed live zap run?

I put screenshots in my original post of these things already :)

Those appear to be screenshots from your Zap setup in the Zapier editor. I’m talking about the input and output data from a live Zap run, which you can find at https://zapier.com/app/history

Ah sorry, I see!

Here’s the input/output of the App Extension:

DATE IN:

fields:

>{"description": "Name of the apartment", "name": "Apartment Name", "type": "singleLineText"}]

baseId:

appaooPBFcKv5jH40

name:

>TEST] Copy of 11/27/23-12/3/23

description:

Copy of 11/27/23-12/3/23 (Sheet ID: 2124391743)

DATA OUT:

request:method:

POST

url:

https://api.airtable.com/v0/meta/bases/appaooPBFcKv5jH40/tables

querystring:

null

headers:Content-Type:

application/json

body:

{"description": "{{description}}", "fields": {{fields}}, "name": "{{name}}"}

data:

null

response:status:

422

headers:

body:

{"error":{"type":"INVALID_REQUEST_BODY","message":"Could not parse request body"}}

data:error:type:

INVALID_REQUEST_BODY

message:

Could not parse request body

So, after looking more at this, I realised that it always sent data:null instead of what the app extension is meant to be sending.

After experimenting with different body data, it seems that if I set the API input in plain text, it works fine. But if I use the {{keyname}} placeholders in a JSON request body, then it fails and sends it as null.

It appears to be a Zapier bug, rather than user error now.

@Katrina_Storm 

An alternative to App Extensions is to use the API Request.

Ah thanks, I didn’t realise there was a difference between them. I’ll give it a try and see how that goes! :)

@Katrina_Storm

An alternative to App Extensions is to use the API Request.

 

Thanks, this worked perfectly!