I receive a 400 error when using Notion API for non-text properties. New code:
async function addPage(){await nb.insert({db:"x",t:"T"});}
Suggestions?
The error might be occurring because non-text properties require a more structured format than just a string. I experienced a similar issue when I tried to pass a simple data type without properly wrapping it into an object format that Notion expects. In my case, changing the way I structured the payload by specifying the type and value explicitly resolved the issue. It may be useful to consult the latest API docs to verify the expected structure for each property type, ensuring all fields are correctly formatted.
hey emma, try wrapping your props into the expected object schema. i had a simlar issue with numeric props that gave 400 errors until i explicitly specified type & value. maybe check if your keys are fully matching notion docs. good luck!
I encountered a similar issue when handling non-text properties with the Notion API. The solution involved ensuring that each property was formatted as an object with clearly defined type and value fields, rather than passing a simple string. My experience taught me to closely follow the API documentation, as even small deviations from the expected schema can lead to errors. Once I adjusted the payload to explicitly specify the data structure, the problem resolved. Reviewing and restructuring the code accordingly may help resolve the error you are experiencing.
hey emma, seems like non-text props need a proper object structure, not just a string. i had a similar issue when i forgot to format fields correctly. check the datatypes in your request, it might be the cause.
Based on my experience, the key was to ensure that each property, regardless of type, was enveloped in the structure that Notion expects. I ran into a similar glitch where a property like a date or a multi-select was just passed as a string. After spending some time with the documentation and testing out structured formats, I adjusted my payload and the 400 error disappeared. So taking the time to build the data with explicit types and values proved to be a useful troubleshooting step.