This is my first post, though many of you will recognize my user name.
I've been able to make the following cURL work from postman, but it fails when set up using cURL options with Insert from URL (using FMP 16 for reasons I won't go into here).
In postman, this works: (To preserve proper security, I've removed key info with "goes here" entries in two places and modified the email address shown.)
I've also had to replace the first part of the text of URL text in these examples with XXXX as I get an error that I'm including too many links in my post (as a new user) if I don't. Presumably there's some way to post cURL examples without the software thinking that I've posted a link, but that's another issue for discusson.
In FileMaker, this fails:
"
--location --request POST 'XXXXX://co1.qualtrics.com/API/v3/mailinglists/ML_mailinglistIDHere/contacts'
--header 'X-API-TOKEN: SiteIssuedTokengoesHere'
--header 'Content-Type: application/json'
-d '{
"firstName": "Phil",
"lastName": "Caulkins",
"email": "PCaulkins@domain.org",
"language": "en",
"unsubscribed": true
}'
"
The message in the inserted result JSON states that the site is looking for the Token in the header and is unable to find it.
Perhaps FMP can't handle two --header entries?
I suppose that I can use the Base Elements plug in for this instead but like to stay independent of plug-ins if a native FileMaker feature can do the job.
Regarding this issue, can you try the same code in FM17 or FM18? Also, are you inserting the result to a field or to a variable - can you try switching that around?
I'll try to see in cals I'm making to other destinations if I am using double headers or not.
I know that with at least a GET, I am using two --header entries. For other requests (post, put, ...), I had to build the insert differently and relied on Geist's HTTP ( {request} ) script. I forgot what's the file they use to distribue it. It's probably included in many of their files from Karbon to Generator.
And store the json you made in $data. Fm will do the substitution for you. Note the @ part, it’s not concatenation. you can build the json with JSONSetElement of course, no escaping necessary.
EDIT: removed pesky "smart" quotes.
Also, I generally like to retrieve the response headers too. To do so, add this curl option (verbatim): --dump-header $responseHeaders to save them to that variable (again, not concatenation, and this time no @ like with -d)
I'm inserting into a field at this time. It has to work in FM 16 so getting it to work in 17 or 18 would be minimally helpful as that would only tell me that I can't use Insert from URL FM 16 for this particular site.
That said, I get the same result with FMP 17 and the same error if I specify a variable as the target.
Given that site can't find the token in the header at all, I would postulate that the issue is in how the cURL header is constructed though I can't find anything wrong in how I set it up.
Only French Canadians will get it planteg! When we franglish we say "je feel (pronounced fil, or phil) good aujourd'hui" for example... So pheeel better planteg loll
@PhilModJunk And welcome! You were the first person to ever answer a question for me on the community years ago. It went something like:
Me: "How do I replace the contents of a field for the found set?"
You: "Replace Field Contents"
Me: "But how do I do it for the found set?"
You: "I repeat, Replace Field Contents"
haha, hopefully I can return one of the many favors owed.
Here's what I had to change to make it work:
a) replaced single quotes (') with escaped double quotes (")
b) Set a variable to the data JSON and inserted @$JSONVariableNameHere into place of the explicitly quoted JSON.
I experimented with keeping or removing the HTTPS text to the right of POST and found that including or removing it made no difference in the result so I'm removing that text in respect for the KISS principle.
Likewise, it was not necessary to put --location on its own row as one reply seemed to suggest. I suspect that I can remove that cURL option completely and only put it here, because postman inserted that option when I copy/pasted the sample code from the site's API documentation.
Glad you got it working! FYI, the --location curl option can affect the behavior of the request, namely cause it to automatically resend the request to the new, moved location when a 3xx response is received. Curl -L Option
This can be un/desirable depending on the situation.
For example, I wrote an API a while back that returned a new request that I wanted the calling app to run, so a --location header in the calling app did so automatically. Cool.
However, another time, I had --location specified in a request for CSV data, but when the website went under maintenance, my request was being redirected to an HTML "Under Construction" page and my app was not equipped to detect the HTML. Therefore, a simple failure on 30X status would have been more desirable in that case.
I guess you can mark your own reply as the answer to the question.
Out of curiosity, have you tried keeping the JSON data and not use a variable? I'm just curious if your answer means you had to change both things for it to work or if you could have changed only one of them.
I’m 99% certain you can get it to work with the JSON embedded directly in the curl. However the @$var approach has been easier and more reliable in my experience.
The example you posted above looks valid e.g. so its more a matter of taste in the case of json post data. Container data may be a different story though.
I figured that a literal JSON would work also, but once the token was being detected, the error messages changed to text indicating that the JSON wasn't formed correctly so using JSON functions to build it in a variable was a reasonable approach and is the final change that got it to work.
I double checked and indeed you can nest JSON directly in the curl options calculation, but escaping all the quotations is a chore because the JSON itself has to be wrapped in doublequotes:
Quote() would work too, as long as there are no carriage returns in the JSON, because pilcrows will break it.
EDIT 2020-03-14: please note that the cURL in the picture above should use -H for header, not -h. Whoops! But that explains the trailing : in the Body received by postbin.
.
.