Build with FAIGEN.
Explore the FAIGEN AI architecture, image-generation workflow and integration principles. This documentation separates the existing authenticated service from any future public developer API.
What is FAIGEN?
FAIGEN is the AI intelligence layer in the sCloud ecosystem. It connects AI capabilities with applications, tools and workflows through an authenticated service architecture.
Route supported requests to the appropriate AI tools and workflow handlers.
Submit image-generation tasks and retrieve generated image results.
Support file and project workflows where the authenticated toolset permits them.
Designed around the sCloud and sC01 infrastructure ecosystem.
Architecture
The existing FAIGEN integration uses an authenticated application flow. A request is processed by the FAIGEN service, routed to the relevant capability, and returned to the calling application.
Application | v Authenticated FAIGEN integration | v Brain endpoint / task processing | +------ AI response | +------ Image-generation workflow | +------ Other authorised tools | v Result returned to the application
Authentication
FAIGEN's existing integration uses authenticated account context and server-side task processing. Do not assume that a browser session or internal identity envelope constitutes a public API credential.
For application developers
- Keep session cookies and secret credentials on trusted server-side components.
- Never embed private keys, internal user identifiers or service secrets in public JavaScript.
- Authenticate users before granting access to private tasks or generated files.
- Verify ownership and permissions on every task lookup and file download.
Brain endpoint
The known FAIGEN brain integration endpoint is:
https://faigen.live/api/brain_endpoint.php
Used by the existing FAIGEN integration. Its complete public request schema, supported HTTP methods and external authentication contract are not specified by this documentation.
Before integrating
Confirm the accepted request fields, session requirements, task-submission behaviour and error responses against the deployed endpoint source code.
Do not send arbitrary requests to a production endpoint to discover its behaviour, and do not expose internal service credentials to a client application.
Image generation
FAIGEN's image-generation tool accepts a prompt and supports optional width and height settings. The authenticated server-side workflow submits a generation job to its image engine, waits for the result and publishes the generated file under a user-specific directory.
Known tool inputs
| Field | Purpose | Availability |
|---|---|---|
prompt |
Text describing the image to generate. | Required |
width |
Requested image width. | Optional; implementation default is 768 |
height |
Requested image height. | Optional; implementation default is 768 |
Generation result
The internal workflow can return fields including
success,
task_id,
uid,
filename,
public_url,
width and
height.
Generated files are published under a user-specific directory. A returned URL should only be made available to people authorised to access the corresponding image. Do not treat possession of a URL as proof of ownership.
Task lifecycle
The existing application integration processes tasks asynchronously. In the known task workflow, the application can encounter these states:
| Status | Meaning | Application behaviour |
|---|---|---|
| PENDING | The task has not completed. | Wait for a subsequent result according to the implemented polling flow. |
| COMPLETED | The task has completed. | Read the returned response. |
| FAILED | The task failed. | Handle the failure and allow a safe retry where appropriate. |
The precise polling URL, submission parameters, retry policy and response envelope depend on the deployed integration. Confirm these details before implementing a third-party client.
Response handling
Design your client to validate responses and distinguish a completed task from a failed or still-pending task. The following is an illustrative internal result shape, not a guaranteed response returned by every endpoint.
{
"success": true,
"task_id": "EXAMPLE_TASK_ID",
"uid": 0,
"filename": "EXAMPLE_FILENAME.png",
"public_url": "https://faigen.live/users/...",
"width": 768,
"height": 768
}
The identifiers and URL above are placeholders. A real response must be obtained from the authenticated service; do not use the example as a valid task or file.
Errors & recovery
Handle errors according to the actual HTTP status and response body returned by the endpoint you integrate with. The following are general client-side practices, not a published FAIGEN error-code catalogue.
- Authentication failure: re-establish the authorised session or credential.
- Invalid input: validate the prompt and any supported dimensions before submission.
- Pending task: continue the documented polling flow without submitting duplicate work.
- Generation failure: report the failure and retry only when appropriate.
- Network failure: use bounded retries and backoff; avoid duplicate submissions where task creation may already have succeeded.
Security best practices
- Keep all secret credentials out of source code distributed to users and out of browser storage.
- Enforce authentication and authorisation on the server for each protected operation.
- Check ownership of task IDs, generated files and account resources.
- Validate input and enforce appropriate size, format and resource limits.
- Use HTTPS for communication between clients and services.
- Do not expose internal network addresses, engine credentials, session identifiers or debugging traces.
- Keep operational logs free of passwords, tokens and unnecessary sensitive prompt content.
Limits & availability
Generation time, supported dimensions, concurrency, quotas and availability may depend on the model, server capacity, account permissions and current implementation.
No public numeric rate limit, guaranteed response time, service-level agreement or public API quota is specified here. Do not build integrations around assumed limits.
Developer support
For FAIGEN product information and image-generation capabilities, visit the official service.
Before publishing a public developer API, provide a verified authentication method, request schemas, endpoint definitions, error formats, usage limits and a monitored developer-support contact.