Any one else see the following problem.
I use zendesk API and pipeline deals api.
code has been in use for 2 months (no issues all working)
As of this week (no changes to the code) both API's fail on post with create calls (Gets work fine and authentication also working fine for both API's).
The execution log shows correct data being encoded example below (removed actual values)
UrlFetchApp.fetch([https://supernahelp.zendesk.com/api/v2/organizations.json, {headers={Authorization=Basic someencodedauthdata, Content-Type=application/json}, method=post, payload={"organization":{"name":"somecustomer","domain_names":"xyc.edu","organization_fields":{"supernauniqueid":"Sup-2308233814","crmdashboard":"someurladdedhere"}}}, muteHttpExceptions=true}])
The payload was passed through JSON.stringify to add to API call and has been working fine for ever.
Error return to from execution log "call to make to ZD {"error":"RecordInvalid","description":"Record validation errors","details":{"name":[{"description":"Name: cannot be blank","error":"BlankValue"}"
Which basically means API could not parse the body correctly for the name value which was sent
I opened case with Zendesk and they got there logs and showed me what they received (not the same record)
only a snippet
{"{\"organization\":{\"name\":\"customer name here \"
I noticed \ added to the payload (not by my code) but this was added by GAS.
AND
Pipeline API has same issue payload Post commands are rejected with bad payload.
Both failed on the same day, and no longer work at all.
this tells me others must have issue with post commands?
looking for help as code worked fine and then stopped and it looks like GAS is adding escape codes out of the blue
Andrew
GAS was broken, seems content type encoding into headers stopped working and moving the content type ad syntax was changed (broke many others scripts as well).
https://code.google.com/p/google-apps-script-issues/issues/detail?id=5585&can=6&colspec=Stars%20Opened%20ID%20Type%20Status%20Summary%20Component%20Owner
Andrew
Related
I'm trying to send xAPI statements from an "Activity Provider" to the ADL LRS live demo. The goal is to implement this from my C# .NET application, but I was having trouble implementing it so I tried running a simple POST request from JMeter.
I do get a 200 response, but when I try to check whether the statement was successfully stored at https://lrs.adlnet.gov/me/statements, it's empty.
Am I completely misunderstanding how this structure is supposed to work? I'm going to install the ADL LRS eventually for testing purposes, but I wanted to get the actual request structure worked out first.
The path looks incorrect, the POST should be to {endpoint}/statements, so in your case it looks like it should be https://lrs.adlnet.gov/xAPI/statements. Additionally you should make sure you are setting the X-Experience-API-Version header. If this doesn't solve the issue, you should look at more than just the response status code, and see what the body contains (and add it to your question). The body for the type of request you are sending should return JSON, with an array with a single statement identifier in it. Additionally when you retrieve the statements the URL you use should match the one that you specify when you send, so /me/ is not correct.
If it is a basic C# .NET project you may be interested in https://github.com/RusticiSoftware/TinCan.NET. It is showing its age, but in general for a number of projects it will still work or would at least be a reasonable place to start.
After updating ra-data-simple-rest from 3.3.2 to 3.10.4 every request to our API for lists started to fail with Error 416 Range Not Satisfiable.
Backend did not change and we are still Allowing and returning Content-Range Header as prescribed by ReactAdmin documentation
ie:
headers:
{
'Access-Control-Expose-Headers': 'Content-Range',
'Content-Range': 'myresource 0-50/32'
}
}
I checked the source code of ReactAdmin Data Simple Rest and from my understanding, the change is related to adding another header Range because of some behavior in Chrome (see history of commits)
Since then though, all the queries made via ReactAdmin are failing in the browser due to Error 416 Range Not Satisfieble . Checking with CURL and Postman the request go through and contain every necessary header, properly exposed.
By manually removing that new Range header, just before sending the request with FetchUtils, the problem disappears.
After researching and trying out we found out that the Content-Range approach for pagination used by ReactAdmin was somehow hacky and it is best to use X-Total-Count .
We removed the Header ContentRange entirely, and used XTotalCount instead ( we specified the parameter in the dataProvider/httpclient as documented and the problem was gone.
What i dont understand is why was that happening. I cant see in the code anything that prevents me from still using Content-Range, and unfortunately I did not find any documentation in Changelog or Upgrade (nor Issues) that talk about the problem we had.
So i am wondering if we were doing something wrong in our backend or in the way we use the provider, or the code has a bug which nobody experienced before.
I'm trying to create a backend system with AWS API Gateway and Lambda.
In the past days I created a PUT method for a new API resource, with an API Key as a simple first security step. The PUT method invoke a Lambda function on AWS.
Then I deployed this API to a "prod" stage for some tests.
In the first days everything were working well as expected: I created a call to the API with postman and I received all the data I was expecting.
But a couple of days ago I started to receive always the 429 "Too many requests" response. I created also a new stage, but nothing changed: also the new stage, with the same version or with newer version, is getting always the same error.
The API is not reaching any limit, because they are called 4 or 5 times per day, not per second (checked on CloudWatch). There is no cycle, it is only a single invocation.
I suppose there is no error on the lambda side, because if I test the API in the AWS API Gateway console I get no error (and the lambda was working well in the past, no new changes from that version). The error only shows when I use an external client to test my api (in my case it is Postman).
Can anyone help to solve this problem?
UPDATE: I've just created a POST method on the same resource, with the same parameters and the same lambda. It is working. I wonder if the problem is related to the PUT methods in general or if within 2 days also my POST method will be affected by the same problem.
I had the same problem. I deleted and recreated the deployment. It did work in my case.
Here is a link to errors related to Amazon's API gateway. The last paragraph has additional information on the 429 error you discussed above.
I had the same issue. I created the case in AWS, and they suggested that I implement this dependsOn fix in the template file. Refer: Link
And it worked for me.
I plan on using cloudconverts API API for converting docx files to pdf but im stuck with a File not found (upload failed) error each time i have started a conversion process and request the status of the conversion.
To make sure the file can be reached, i ran a test using their API and executing my request which was a success.
Im testing the conversion using Googles Advanced Rest Client and my header og payload is as follows:
Requesting a process:
Im getting an URL for my convertion process and all is good. So time to start my process of converting my file. Im using the option to let cloudconvert download the docx from my domain.
Starting my process:
The request for starting my process is also a succes and i now want to check the status of my conversion by calling the previous url as a GET. But this gives me an error message in the response saying: File not found (Upload failed)
As written in the beginning of my post, i tried using their API console to test if the file can be downloaded from my site, which it could and PDF was created successfully .. So i guess im missing something somewhere, just cant see it...
So yeah,
First problem was that there was wrong content-type header set. For JSON payload it should be "application/json". With "application/x-www.form-urlencoded" content type header the server expected different payload so the call resulted with error.
Second one was about JSON parsing. JSON is not the same as JavaScript object. Keys in JSON must contain double quotes characters.
Finally I'm not sure what do you mean by success response. If you talking about status code - well it's just bad API configuration/design.
We've recently noticed in our logs that the signature verification has been failing in certain cases (this didn't happen before and started happening in the last few weeks). I investigated further and noticed inconsistencies in the URL params.
Some examples (replaced shop name with "xxx" for privacy reasons):
SUCCESS
/oauth2/shopify?code=7e8ec807e9f4b29b6e6d352ff5a654cc&shop=xxx.myshopify.com×tamp=1353377082&signature=3edc31eb7d93813313e937a9ac1c6f8c
/oauth2/shopify?shop=xxx.myshopify.com&signature=63103f985dabf0f102fe7ce8335c9c4c×tamp=1353377555
FAILURES
/oauth2/shopify?shop=xxx.myshopify.com
/oauth2/shopify?code=&shop=xxx.myshopify.com×tamp=1353361621&signature=91927831bbbe9ca37472c2a3fa260a49
Notice that in the failure cases, parameters are either missing (no timestamp or signature in 1st request) or the "code" parameter is blank (for 2nd request).
This is a confirmed bug with a fix in the pipe. Sorry about the regression!