I’m creating a custom POST endpoint. In testing the basics of the endpoint via Postman, everything works fine, but from the code that needs to call this endpoint—a custom Airtable extension for internal use only, which uses “fetch” to call the endpoint—I’m getting this response: “No ‘Access-Control-Allow-Origin’ header is present on the requested resource.” I read up on how to address this and created a second OPTIONS endpoint to handle the CORS preflight request and send the proper headers, but that hasn’t made a difference.
Here’s the code for both endpoints so far:
import { ok, badRequest, response } from 'wix-http-functions';
export function options_mlfiles(request) {
console.log("In the option function")
const responseObj = {
"headers": {
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Methods": "POST, OPTIONS",
"Access-Control-Max-Age": 25
},
"status": 204
};
return response(responseObj)
}
export function post_mlfiles(request) {
console.log("In the post function")
console.log(request.body)
const responseObj = {
"headers": {
"Content-Type": "application/json"
},
body: JSON.stringify({
result: "It worked from this end."
})
};
return ok(responseObj)
}
At this point I’d be happy if the console.log() statements would work, but nothing shows up in the Developer Console during my test calls to the main endpoint, even when calling from Postman where I get a successful response.
FWIW, I’m using the wildcard for the “Access-Control-Allow-Origin” header because the call is going to be coming from a rather cryptic URL on Airtable’s server (currently “https://devblock---ok-c-w-s-h-j5c-zd-o-vk--nss8z64.alt.airtableblocks.com”), but that’s not likely to remain consistent during development, and less likely to be the same after release. If that origin changes to something more consistent when the app is released, I might use that instead, but the wildcard option should still work for now, and it’s not.