Authentication
The Simplio3D API uses JWT tokens for authentication. All API requests must include a valid access token.
Sign Up
const response = await fetch(BASE_URL + '/auth/signup', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
email: '[email protected]',
password: 'securePassword123',
name: 'John Doe'
})
});
const data = await response.json();
// { "success": true, "userId": "...", "message": "Account created" }Sign In
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);
const { data: { session }, error } = await supabase.auth.signInWithPassword({
email: '[email protected]',
password: 'securePassword123'
});
// Use session.access_token for all API calls
const accessToken = session.access_token;Get Session
const response = await fetch(BASE_URL + '/auth/session', {
headers: { 'Authorization': 'Bearer ' + accessToken }
});
const data = await response.json();
// { "success": true, "userId": "...", "email": "[email protected]" }Using Access Tokens
Include the access token in the Authorization header for all authenticated requests:
Authorization: Bearer YOUR_ACCESS_TOKENAPI tokens (X-API-Key)
An account can issue a long-lived API token from Profile → API/SDK for server-to-server automation. It is sent in its own header:
X-API-Key: YOUR_API_TOKENAn API token does not replace an access token. It is accepted on a deliberately narrow set of endpoints — everything else returns 401:
Accepts X-API-Key | Requires Authorization: Bearer |
|---|---|
/projects/:id/option-blocks (+ /reorder, /evaluate)/projects/:id/pricing-blocks (+ /calculate)/projects/:id/quote-submissions (read/update/delete)/projects/:id/webhooks (+ /test) | Everything else — including GET /projects/:id, projects, materials, assets, categories, form fields, animations, settings, sharing, team, profile and token management. |
So an API token can read and author a project’s option blocks and pricing, but cannot fetch the project itself. If you need the full surface, sign in and use the resulting access token.
Never ship an API token to end users
An API token authenticates as the issuing account across all of its projects. Anything distributed — a mobile or desktop app, or browser JavaScript — can be decompiled or proxied, so an embedded token is a published one. It is also disabled while a subscription is inactive and rotated automatically 90 days after a lapse. Keep it server-side; for customer-facing apps use the public share endpoints (see Mobile & native apps).
CORS
The API answers cross-origin browser requests by reflecting the requesting origin back in Access-Control-Allow-Origin and setting Access-Control-Allow-Credentials: true. There is no origin allow-list to register, so a browser on any domain can call the API — what it may send is constrained by the header list below, and what it may do is constrained by the credential it presents.
| Allowed origins | The request’s own Origin, reflected. Requests with no Origin (server-to-server, curl, Postman) are allowed. |
| Allowed methods | GET, POST, PUT, DELETE, PATCH, OPTIONS |
| Allowed request headers | Content-Type, Authorization, X-Client-Info, apikey, X-Share-Password, X-Workspace-Id |
| Exposed response headers | Content-Length, Content-Type |
| Credentials | true |
X-API-Key is not in the allowed-header list — on purpose
Because X-API-Key is absent from Access-Control-Allow-Headers, a browser’s OPTIONS preflight for a cross-origin request carrying that header fails, and the real request is never sent. You will see a generic CORS error in the console rather than a 401, because the call never reached the API.
This is a guard rail, not a gap. An API token must never reach a browser in the first place — anything shipped to a page can be read out of it. Use X-API-Key from your own server, and give browsers either a user’s Authorization: Bearer access token or the public share credentials.
