curl -X POST https://kymaapi.com/v1/auth/login \
-H "Content-Type: application/json" \
-d '{"email": "you@email.com", "password": "your_password"}'
Endpoints
Login
Sign in and get a session token.
POST
/
v1
/
auth
/
login
curl -X POST https://kymaapi.com/v1/auth/login \
-H "Content-Type: application/json" \
-d '{"email": "you@email.com", "password": "your_password"}'
string
required
Your email address.
string
required
Your password.
Response
{
"user_id": "abc123",
"session_token": "ks-your-session-token"
}
Errors
| Status | error.type | When |
|---|---|---|
400 | invalid_request | Invalid JSON, or email or password missing |
401 | invalid_credentials | Unknown email or wrong password. An account created with Google sign-in has no password: sign in with Google. |
429 | rate_limited | Too many failed attempts for this email or from your network. Try again in 15 minutes. |
Session cookie
When the browser session cookie is enabled, a successful response also carries twoSet-Cookie headers. They are additional to the JSON body, which is
unchanged — session_token is still the credential to store and send as
Authorization: Bearer ….
Set-Cookie: __Host-kyma_session=ks-…; Path=/; Max-Age=2592000; Secure; HttpOnly; SameSite=Lax
Set-Cookie: kyma_csrf=…; Path=/; Max-Age=2592000; Secure; SameSite=Lax
__Host-kyma_session is host-only and HttpOnly: it is sent by the browser to
kymaapi.com only, and page scripts cannot read it. kyma_csrf is readable, and
a request authenticated by the cookie alone must echo it in an X-Kyma-CSRF
header on any POST, PUT, PATCH or DELETE; requests that send a Bearer
token need nothing extra. POST /v1/auth/logout clears both.
API clients that do not keep a cookie jar are unaffected — ignore the headers and
use the Bearer token as before.
curl -X POST https://kymaapi.com/v1/auth/login \
-H "Content-Type: application/json" \
-d '{"email": "you@email.com", "password": "your_password"}'