# CORS Preflight method with Ion API GW integration

**URL:** <https://forum.datomic.com/t/cors-preflight-method-with-ion-api-gw-integration/925>\
**Category:** Datomic Cloud\
**Created:** [April 12, 2019, 3:33am UTC](https://forum.datomic.com/t/cors-preflight-method-with-ion-api-gw-integration/925 "2019-04-12T03:33:21Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![caleb](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/caleb/32/87_2.png) [@caleb](https://forum.datomic.com/u/caleb)\
**Post date:** [April 12, 2019, 3:33am UTC](https://forum.datomic.com/t/cors-preflight-method-with-ion-api-gw-integration/925/1 "2019-04-12T03:33:22Z")

</div>

I have an Ion set up with API Gateway integration. The works as expected. Today I have been trying to add an OPTIONS method to the resource as describe [here](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html#how-to-cors-console), so that I can call the API from javascript served from a different domain. I have done this before and it worked, but I am getting 500s when I try to add it to this resource.

When I enabled logging for my APIGW stage, I saw that the 500 was due to APIGW trying to transform the request body of my OPTIONS request and failing. There is no body, but I can see the APIGW thinks it has binary body content for some reason. I remembered that the Ions tutorial had me add “_/_” as a binary media type for the API. I’m not sure why this is. Is it just to get APIGW to pass the body through as-is? Anyway, when I remove that mapping, the OPTIONS method works and I can invoke the API via js in the browser, but the payload of my proxy method is now coming back base64 encoded. I thought maybe I would just change a setting on the response of my proxy integration to decode that on the way out, but I see that you can’t alter responses for a proxy integration.

I know this question is very heavy on APIGW details (the solution might be going to the non-proxy lambda integration), but I was thinking that this must be something that others have run into and was wondering if there was something I was missing.

---

<div class="post-metadata">

**Author:** ![caleb](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.datomic.com/caleb/32/87_2.png) [@caleb](https://forum.datomic.com/u/caleb)\
**Post date:** [April 12, 2019, 4:19am UTC](https://forum.datomic.com/t/cors-preflight-method-with-ion-api-gw-integration/925/2 "2019-04-12T04:19:25Z")

</div>

After reading the docs a few more times, I see:

> API Gateway will look at the Content-Type and Accept HTTP headers to decide how to handle the body.

So if I add application/edn (what my ion is returing) as a Binary Media Type _ **and** _ add “Accept: application/edn” to the requests, API Gateway sends the response back as I return it from my ion (not based64 encoded).

---

<div class="post-metadata">

**Author:** ![adamtait](https://avatars.discourse-cdn.com/v4/letter/a/35a633/32.png) [@adamtait](https://forum.datomic.com/u/adamtait)\
**Post date:** [October 5, 2019, 9:43pm UTC](https://forum.datomic.com/t/cors-preflight-method-with-ion-api-gw-integration/925/3 "2019-10-05T21:43:48Z")

</div>

I encountered the same issue but caleb’s solution didn’t work for me. I wasn’t able to get an OPTIONS request to return HTTP/200 until I followed [the advice here](https://forums.aws.amazon.com/thread.jspa?threadID=256140) and updated the content handling for the OPTIONS resource.
