Support APIs¶

These endpoints support identity inspection, encryption, publication storage, UI monitoring, and server health. Paths are relative to the API base URL. They do not all use the same authentication dependency.

Identity, certificates, and health¶

An ingress or authentication proxy can impose additional access restrictions. The health response uses a string value, not the boolean true. It is a liveliness response, not a check of GitLab, storage, databases, launcher availability, or capacity to execute a workflow.

UserInfo¶

The response is not an OAuth token endpoint and does not issue or refresh credentials. A masked GitLab token is not a usable repository credential. See Authentication for the provider-specific credential to send.

Public encryption key¶

The certificate resource returns the public JWK used to encrypt profile secrets for this AntFlow instance. It must not expose private key material. Unavailable or invalid server key configuration returns 500 with a detail message. This is not the identity provider's signing-key set or an API token. Use the same instance's key and profile configuration; see Manage workflow secrets.

Data access¶

The user data prefix is /data; the worker prefix is /launchers/{id_launcher}/data. Each exposes these operations:

job_id identifies the published job; file_path is relative to that job's stored publication prefix, not a filesystem path on the server. Use returned data links instead of inferring bucket keys.

User GET/PUT requests resolve a user API credential and enforce job visibility. Worker GET/PUT requests authenticate the launcher token and resolve the server's GitLab token for storage authorization. Configure that server token when using the launcher storage interface; possession of an instance URL alone is insufficient.

The current HEAD/OPTIONS handlers do not read the object or perform the GET/PUT job lookup. Their response does not prove file existence or authorization to read or write it. CORS middleware can also handle browser preflight requests.

GET behavior depends on the configured presigned-path regex: matching paths redirect; others are proxied with the upstream status and content type. PUT prepares a redirect rather than persisting the object itself; the client must perform the signed upload. Uploads can create or overwrite stored job data and are not a user job-submission mechanism.

Keep presigned URLs secret until they expire. Never forward an AntFlow Bearer token to a different storage host using --location-trusted. Follow Download files for safe user downloads and Store and serve workflow results for bucket and result-delivery settings.

Monitoring¶

These endpoints use user API credentials and expose UI-oriented summaries, not another job-execution protocol.

Monitor parameters¶

MonitorData contains pagination and processes. Pagination is serialized with page, limit, total, total-pages, prev-page, and next-page. total counts jobs while page counts and limits concern grouped processes; do not treat it as the number of process groups.

Each process group includes id, link, project, project_path, commit_ref, total, counts for each user-facing status, and runs. Run summaries include a job link, status, progress, timestamps, reference, commit, optional user, comment, and tags. Ordinary-user visibility is filtered; administrator summaries can cover more jobs.

Process metadata parameters¶

Supply process_id, project_path, and project_ref as query strings. The handler can use the project's default branch for descriptive metadata and fall back to the supplied reference; this endpoint is not a guarantee of immutable metadata for the execution commit.

MonitorProcessInfo contains process_id, optional process_title and process_description, project_name, the resolved project_ref, and an optional project link. For exact process inputs and execution choices, use the project process description, not this monitoring summary.