I am using FM 17 and am trying to submit some JSON to an 3rd party website to create and insurance claim.  Below is the curl code I am able to run from the command line. 

I tried using Insert From Url to do the same thing and I am unable to get it to work.  I get the following message back when I use Insert From Url: "Message": "The requested resource does not support http method 'GET'."  I need both the information after the question mark on the url and the data after the -d tag.  I think I read somewhere that if a ? and information is included after the url that Filemaker's implementation of Insert From Url assumes a get.  I need to be able to have both and do a post.  Am I missing something?  Any help would be appreciated.  I can use Send Events but would rather use Insert From Url

curl -o apexEdiOutput.txt -X POST https://sandbox.services.apexedi.com/api/V3/claims/submit?vendorSiteId=<vendor site id> --header "Authorization: Basic <base 64 encoded key>" --header "Content-Type: application/json" -d "@<path name and file with json>"

Thanks!

In your FM call are you also pointing to the json file on the hard drive somewhere?  That won't work.  FM does not allow sending files like that (for security reasons).  If you have the json in a variable then you can just use -d @$json

Other than that we'd have to see your Insert From URL script step and its cURL options

Hmm ... thanks for the input Wim.

I went back and looked at my call to Insert from URL and now have the following code:

Insert from URL [Select; With dialog:On; Trans::_temp field;
"https://sandbox.services.apexedi.com/api/v3/claims/submit?vendorSiteID=<our id>,type=medical;
cURL options:"--location --dump-header $curlHeader --show-error -o $curlOutput -X POST --header \"Authorization: Basic $apexBase64EncodedKey\" --header \"Content-Type: application/json\" --data  & @$claimDataJSON"

I no longer get the message "The request resource does not suport http method Get" but it does redirect it to a production url instead of the test sandbox and says I'm not authorized.  Which is true.  Does anyone know why this is happening?

1627
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 41
Content-Type: text/plain; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
WWW-Authenticate: Basic Scheme='OneTouchWebServiceV3' location='https://production.services.apexedi.com/'
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 11 Nov 2019 23:37:57 GMT

Keep in mind I can post to the sandbox url using curl and send event.  So either I am or Filemaker is doing something different/wrong on the Insert from Url call.

Thanks for everyone's help.  Hopefully, I can be helpful to someone sometime.

Edited November 11, 20196 yr by JMW

12 hours ago, JMW said:

cURL options:"--location --dump-header $curlHeader --show-error -o $curlOutput -X POST --header \"Authorization: Basic $apexBase64EncodedKey\" --header \"Content-Type: application/json\" --data  & @$claimDataJSON"

 

 

The section indicated in red is incorrect.  Unlike sending data that is in a variable you cannot do the same for the authorization part.  That has to be a real concatenation:

"...Authorization: Basic " & $apexBase64EncodedKey & "....

 

I think the reference to production in the response is a red herring, it's probably a reference to where they authenticate.

Wim,

Thanks for the tip.  It didn't seem to solve the problem in the long run.  It worked for awhile and then stopped, which seems weird.

Edited November 13, 20196 yr by JMW

Wim,

It turns out that your solution was correct!  The website I was interfacing with had stopped accepting requests from our userid.  

On 11/12/2019 at 5:36 AM, Wim Decorte said:

 

"The section indicated in red is incorrect.  Unlike sending data that is in a variable you cannot do the same for the authorization part.  That has to be a real concatenation:"

Does this imply that a field can't be used for the base 64 encoded key and used in place of the variable?

Edited November 18, 20196 yr by JMW

40 minutes ago, JMW said:

Wim,

Does this imply that a field can't be used for the base 64 encoded key and used in place of the variable?

 

No, you can still do that.  But unlike the variable used for sending data, in this case you just need to properly concatenate things like in my example.