Its working on AWS server without stringify response object....But fails in local environment.
Error :
According to the API Gateway specs, the body content must be stringified. Check your Lambda response and make sure you are invoking JSON.stringify(YOUR_CONTENT) on your body object
I tried both version i.e "serverless-offline": "^3.15.3" and "serverless-offline": "^3.25.x"
Can you point out the differences between AWS and serverless-offline with an example please ?
I ran into the same issue. I am using serverless haskell. See the top right corner for the change I made (disabling the JSON.stringify check entirely) and the bottom left corner for google chrome correctly parsing the response.

How are we going to follow-up?
@Avinash2368 Thanks for raising this issue. Can you create a minimum reproducible example and link it here? Thanks.
Reproducing this is as easy as returning this JSON from a lambda...
{
"body": "{\"some\": \"message\"}",
"isBase64Encoded": false,
"statusCode": 500,
}
... which fails this check, raises an error, and generates an internal server error.
This is the necessary format for returning JSON via Lambda Proxy integration, also.
I just realized the issue I posted is related to but slightly different from the reported one - mine is when stringifying the response body per the AWS docs. If I change...
"body": "{\"some\": \"message\"}"
... to...
"body": {"some": "message"}
... that sample payload will result in the original error reported: According to the API Gateway specs, the body content must be stringified ...
I'm using a Python lambda (with the default "lambda proxy" integration) and can confirm that the response body does not need to be stringified, though I cannot find anything in the AWS docs that support this.
Edit: Huh, I can't find anything here that says the body should be JSON-stringified, either, though I know I read that somewhere. 馃し鈥嶁檪
Edit 2: This link explicitly states that the body if returning JSON needs to return a stringified version, though it was published Oct. 2017
Hi, I have a similar issue here with lambda integration. It should be fine to execute lambda callback with a non-stringified response if you are using lambda-integration. I am not sure why we still need to check for lambda integration mode here https://github.com/dherault/serverless-offline/blob/a3e0bc50b87babec8baee506d0ffbd1528d25067/src/index.js#L861
Most of our response still works though because it does not contain a body field in the HTTP response body.
BTW i am using node runtime
Is there any timeline on this being fixed? It is a big pain when attempting to test changes locally.
Most helpful comment
Is there any timeline on this being fixed? It is a big pain when attempting to test changes locally.