Got a Node 18 Lambda handling Genesys Cloud webhooks. The event body is a stringified JSON. When I run JSON.parse(event.body), it blows up with SyntaxError: Unexpected token o in JSON at position 1. Seems like event.body is already an object? Or maybe the signature verification is messing with the buffer. Anyone hit this? Here’s the handler:
exports.handler = async (event) => {
console.log('Raw:', typeof event.body);
const payload = JSON.parse(event.body);
};Are you using the http-api payload format version 2.0? If so, the body is already a parsed object, so calling JSON.parse on it throws that exact error since it starts with { or [. Just drop the parse call and access event.body directly.
is spot on. That Unexpected token o is the classic signature of trying to parse an object that’s already been deserialized by the runtime. In v2.0 payload format, AWS does the heavy lifting for you, so event.body is a plain JS object, not a string. Calling JSON.parse on it is basically asking it to parse the string "[object Object]", which fails immediately.
Since I’m stuck in the .NET world, I usually see this mirrored when folks use Newtonsoft.Json or System.Text.Json on a deserialized JObject or JsonElement. You don’t need to parse it again. Just access the properties directly.
Here is how I structure my Lambda handlers in C# to avoid this exact headache, using System.Text.Json for speed. The key is checking if the body is already a complex type. If you are sticking to Node, your handler should look like this:
exports.handler = async (event) => {
// Check payload format version if available, or just try accessing as object
let body = event.body;
// If it's an object, use it. If it's a string (v1.0), parse it.
if (typeof body === 'string') {
try {
body = JSON.parse(body);
} catch (e) {
console.error('Failed to parse body:', e);
return { statusCode: 500, body: 'Internal Error' };
}
}
// Now 'body' is an object in both v1.0 and v2.0 formats
console.log('Contact ID:', body.contactId);
return {
statusCode: 200,
body: JSON.stringify({ message: 'Processed' })
};
};
The docs for the API gateway payload format explicitly state that v2.0 is “application/json” by default and parsed. Ignoring that leads to exactly this crash. You might also want to verify the Signature-Verification header isn’t causing issues, but that usually results in a 401 or 403, not a syntax error. Stick to the object access pattern.