Fetch API vs Axios

[TheDunco]

Would it be possible for future versions of the API to use the standard fetch API instead of Axios? From what I've seen Axios is making the API more difficult to work with, as we don't get standard things like response.ok to check successes with.

Another issue is that the errors that come back from the API are nested deep within the {caught error/response}.response.data.errors object and it took me forever to realize that I was actually getting error data back. I'd at least like to see a generic KlaviyoApiError Type exported from the package so we know the shape of the error data that's coming back.

[pete183]

Another reason to support fetch is Axios isn't supported on some runtimes such as Vercel serverless

- adapter xhr is not supported by the environment
- adapter http is not available in the build
    at new Promise (<anonymous>)```

[pauldraper]

Well this is klaviyo-api-node :P

[charkour]

Vercel serverless functions execute a Node process: https://vercel.com/docs/functions/runtimes/node-js

[pauldraper]

Yeah, maybe @pete183 is referring to Vercel Edge?

[Ian-Montgomery-Klaviyo]

The team is looking into switching to fetch.