API requests, authentication and responses
API base URL: https://api.syauth.com/e/v1. A route shown as /e/v1/login/ becomes https://api.syauth.com/e/v1/login/; do not append /e/v1 twice.
How to use the API reference
The reference is for looking up one operation while writing or testing requests. It does not describe a complete login journey in page order. For a guided first test, use the browser walkthrough without an app or the first management request.
For a particular operation, read its HTTP method and address, the required credential/scope, the required fields, and then the response examples. A request is what you send; a response is what SyAuth returns. Success and error examples show alternative outcomes for that request. You do not need to reproduce every example to complete a test.
If a response returns an ID, token or code that a later request needs, use the actual value you received. A schema is a description of the fields; it is not a token or another command to run. See plain-language terms.
Requests
Send Content-Type: application/json for JSON bodies and Accept: application/json for JSON APIs. OAuth token/revocation also accept URL-encoded forms. Hosted pages and SAML browser flows return HTML, XML or redirects. SCIM write requests currently use application/json and responses use application/scim+json.
Most paths end in /. SCIM resource paths and .well-known JSON paths do not. Follow the exact documented path. Path parameters are required unless stated otherwise; serialize UUIDs as strings. GET requests normally have no body. Some DELETE operations require JSON, such as group membership removal.
Each operation lists its credential, scope, request fields, schema and response examples. Choose the right credential before troubleshooting the payload. Management calls also require an active plan and access to the workspace/resource. Only an owner can perform some operations.
Replace sample values
Examples are templates for your request. Replace placeholder text directly; YOUR_... is not a shell variable. Keep JSON field names and the surrounding quotes, and use the actual values from your dashboard or an earlier response:
| Example value | What to substitute |
|---|---|
YOUR_..., PUBLIC_CLIENT_ID, EXAMPLE_..., sample UUIDs | Your own value for that field. Find resource IDs using the identifier guide; copy credentials from the correct token source. |
{user_id} or another placeholder in a URL path | The actual resource ID, without { or } |
[email protected] | A real email address you control when the flow sends mail |
| Email verification/reset codes or an OAuth authorization code | The code issued for that specific step; these code types are not interchangeable |
OAuth state, nonce, PKCE verifier/challenge | Fresh values generated by your application for that sign-in attempt; use the runnable generator |
JSON strings must escape embedded double quotes as \" and backslashes as \\. In application code, use a JSON serializer rather than building JSON by concatenating strings. Query parameters must be URL-encoded; form examples using --data-urlencode perform that encoding for you.
Combine the operation's required-field description with its schema and request-field table. A table entry such as not supplied describes the absence of a fallback; it is not a value to send and does not make a required field optional. For a complete sequence of requests, follow a sign-in walkthrough or the management walkthrough.
Responses and errors
There is no single response envelope. A list may be an array, a results object, or SCIM Resources. Read pagination fields for the specific endpoint; next can be a boolean rather than a URL. Example IDs, codes, tokens, timestamps and lifetimes are illustrative; use actual values returned by your request.
Errors can contain error, detail, field-specific arrays, OAuth error_description, or a SCIM error object. Keep both HTTP status and response body.
| Status | Typical meaning |
|---|---|
| 400 | Missing/invalid fields or request context |
| 401 | Missing, expired or wrong credential; see availability notes for affected features |
| 403 | Missing scope, resource access, plan or feature permission |
| 404 | Resource not found or not accessible in the selected workspace |
| 409 | Duplicate/conflicting resource |
| 415 | Incorrect request content type |
| 429 | Too many requests |
| 502 / 503 / 504 | Service unavailable or unable to complete the request |
See API troubleshooting. The examples show possible success/error shapes; conditional responses are alternatives, not a sequence of responses to one request.
Integration availability
Some advanced endpoints have a known limitation where a correctly chosen application or protocol credential can still receive 401. These are marked at the operation. See known limitations and confirm availability before deploying the feature. Supplying a developer token to an application-user endpoint is not a supported remedy.