Hi guys, I’m super excited that API is here - the gates are open!
I’m having some trouble configuring everything tho, I can view collection data via GET requests, but POST requests always returns an error…
I’m using Zapier to fire a http request after a Webflow form is being send, however I always get this: “(400) Bad Request” and “ValidationError: Validation Failure”
This is my current setup in Zapier:
I might be doing something completely wrong tho,
any help is greatly appreciated!
Thanks
Is there anyway to see the actual json that zapier is posting? Or to get the full contents of the error object (ValidationError may have a problems key with what actually was wrong)?
I know in the “developers” console in Zapier if you “own” the application, you can see raw requests, but I’m not sure how that works when using “Zapier POST” directly like this.
If you can’t see those requests, the next thing I would look at would be ensuring the collection you’re adding to doesn’t have required fields that you are missing - and that the slug is valid in the data you are sending up.
Hey @nathan, I was looking into that too but haven’t found a way so far.
I also tried it with Zapier Code and wrote the request as given in the examples but also that returned an error,
I think it was a 401 error in this case (for some weird reason the error email Zapier sends just disappears when opening it)
I see the problem now - the fields _archived and _draft are actually required fields and are what is causing the validation error. (The full error that Zapier isn’t showing for some reason is: {"name":"ValidationError", "statusCode":400, "problems":["Field '_archived': Field is required","Field '_draft': Field is required"]})
The current docs are not clear about that - I will update them shortly. Thanks for shining a light on that!
The fix would be to make sure that these fields are all included:
{
"fields": {
"slug": data slug, // exists in zapier config above
"name:": data name, // exists in zapier config above
"_archived": true/false,
"_draft": true/false
}
}
New collection items are being created-yay, but they are ‘Staged for Publish’, is there a way to work around the need to publish your site?
Currently a manual publish is still required. At a minimum, “Publish Site” will be exposed in the api soon.
Potentially in the future there also will be the ability to have items be immediatley published without publishing the site as well - but this gets a bit tricky when schema changes happens, so we are still working on how best to have all those edge cases fit together.
Doesn’t that kinda beats the purpose of rest api? (I know this is still in beta of-course)
Yes might be handy if we could toss that in as a param or something, do you think this will be included in the first official release?
Wow publish site in api is definitely a must! We will need this in V1 minimum?
Definitely +1 for the auto-publish feature. Hope that’s coming soon!
Incidentally, @SidneyOttelohe, Zapier usually exposes the payload that’s being sent around, whether sent or received. If you can’t find it, though, try setting up a RequestBin:
You can create a unique URL for webhooks that expires after 48 hours. Just use this as a POST endpoint for whatever data you’re inspecting and it will show you exactly what you’re looking at. Saved my bacon a few times when trying to get a Cognito form to play nice with my client’s API…
Also, since Zapier doesn’t return error messages, you might try Postman:
There’s a bit of a learning curve but you can test JSON schemas by POSTing them to whatever endpoint before setting up your zap. It will return errors – such as fields that are required or mis-typed – that Zapier doesn’t reveal. Again, I was having a devil of a time with a client API because Zapier wasn’t telling me what was failing, but Postman does! In fact, I think I might fire up a new topic for how I’m using Postman to test out the Webflow API…
