I think it’s because, as mentioned here the api is used “by the Panel to connect between the Vue frontend and the PHP backend.”
In that case it makes sense to require authentication because the api can be used to modify/delete content in the backend and not just read it (if I understand correctly how the api works)
Ahah, thanks for confirming that peeps! I figured that out last night.
Hopefully they will add other methods to use it for making spa, etc. I’m sure they will…
I’m still waiting with my fingers crossed, hoping that we all missed something and that we get an official answer showing how to use the api for an SPA 
But yeah, unfortunately I don’t think so…
Are you by chance testing the basic auth on Mac using MAMP?
No, not on MAMMP. Using gulp with gulp-connect-php and browsersync as a local server.
Trying to catch up with this thread: Do I understand right that your key issue at the moment is that the API always wants you to authenticate when you want to read data?
Yes, two things:
1 When following the example for the session-based authentication from the docs, it is required that one is authenticated, i.e. logged into the panel.
2 When following the basic auth example from the docs, a 403 error is still happening (in my case and others as reported above).
I’m sure there’s a good reason for it.to reinstate the point that confused some of us who posted on this thread:
being logged-in, whether by actually logging in to the /panel or by sending the user credentials with an API call to kirby is fine. in eg, you want kirby to be a headless cms, and your custom app interacts with the data from kirby in order to change it as well.
the confusion imho arises when understanding REST APIs as also only a way to read the data from an endpoint and use it to make an interface with it. in this case, it feels out of place to have to be logged in to the panel. or rather, if there’s an option to login to kirby through an API call as well, then i think my problems are solved 
i am up to open a ticket on github if it makes it easier to discuss!
Surely using a data representation would be a better more reliable way to do what you’re trying to do?
Main issue I would see about hooking into the panel endpoints are there is no guarantee that they won’t change with future versions of Kirby.
https://getkirby.com/docs/cookbook/templating/generating-json
Have a look at https://getkirby.com/docs/reference/api/auth/login
I cannot guarantee this 100%, but in general we see the API as something for people to use as well. Not just internally for us to communicate between core and panel. So we wouldn’t just change the endpoints completely erratic but we have others in mind.
That said, I’d also go for content representations. Mainly also because that way you much clearer can define who gets which data.
then i think it makes sense to keep working on plugins like these Spad: Site to json plugin
Why not do it native as mentioned in my link above?
Thats a fair point, my thought could be although the intention is good, it does make it harder for you as the core team to maintain if you need to make breaking changes.
I understand your thinking, but it offers nothing over content representations.
i think it comes down to have to make a content representation template for each template of the website, versus having a plugin that scans your entire /content folder and does the same thing in one go.
but as there are still some limitations with the mentioned plugin due to the new version of kirby, it might indeed be more future-proof to set up the content-representation template yourself…
i’m looking forward to some headless cms / spas use cases though
Why not use params to query into the represenation?
We’ve found the Kirby 3 API and Nuxt to be a great mix, but there are a few parts of the process that need some work.
You’ll probably need to use basic auth for API requests, as your Nuxt/Vue/SPA app may not have easy access to the CSRF field.
See here for how to enable basic auth in your Kirby config https://getkirby.com/docs/guide/api/authentication#http-basic-auth
Second hurdle is that currently Kirby will drop any basic auth API request if it is done without HTTPS. There’s some discussions and pending updates to Kirby that will hopefully resolve this, but for now I am manually patching my Kirby 3 sites to allow non-HTTPS API requests with basic auth.
I create a specific API-only Kirby user in my site. You may need to give this API-specific user reduced permissions. Be aware that a crafty user could reverse the email/password from the API and log in to your panel with the API account if this is used client side.
You might create a Kirby role called api (see Kirby permissions documentation)
Comment out these three lines in your Kirby src/Cms/Auth.php file https://github.com/getkirby/kirby/blob/72f01eac0a7db59360894e0cfb44680276260174/src/Cms/Auth.php#L73-L75
Once you’ve done that your API should work in development. Here’s a snippet of code for setting up the API in your JS app with axios (this will work on the client or server).
const axios = require('axios')
const kirbyEmail = 'api@yoursite.com'
const kirbyPassword = 'api-specific-password'
const kirbyBase = 'http://localhost:8888/kirby-site/api'
const authorization = Buffer.from([
kirbyEmail,
kirbyPassword
].join(':')).toString('base64')
const api = axios.create({
baseURL: kirbyBase,
headers: {
Authorization: `Basic ${authorization}`
}
})
From there, consuming the API in javascript-world looks like:
const res = await api.get('/pages/home')
const page = res.data
I’m working on a Nuxt module for this that will make things simpler. There’s potential to improve the process and support lots of developers wanting to build with Nuxt and the Kirby API.
As mentioned elsewhere the other hurdle to building sites this way is that the API returns raw kirbytext/markdown for text fields.
I’ve got a basic kirbytext to HTML parser that would be helpful but it needs some work.