> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Intake an ASLC file > Receives an ASLC file. aslc_passthrough accepts an already-signed, opaque artifact: it is received, stored and audited WITHOUT parsing its content, and the signature outcome is recorded (never a hard reject). aslc_xml intake is not implemented in this phase (501). The uploading participantId is an explicit, validated body field; the tenant comes from the request identity, never the body. Field presence/type is validated against the schema (422); a bad participantId or non-base64 content is a coded 400. RBAC: operations:write. ## OpenAPI ````yaml en/openapi/v3-current/slc.yaml post /v1/files openapi: 3.1.0 info: description: >- API for Lerian SLC — the participant-side rail that connects the institution to Núclea's SLC deferred-net card settlement. It covers settlement-operation intake and lifecycle, clearing positions, the participant and arrangement registry, generated reports, embedded XSD schema introspection, transmission recovery and connectivity to Núclea, BYOK Model-A signing-key import, and tenant-scoped webhooks. title: Lerian SLC API version: 1.0.0 servers: - url: https://slc.sandbox.lerian.net security: - BearerAuth: [] tags: - description: >- Settlement operation lifecycle — create, list, query, and control the NUliquid-tracked card operations (NUliquid = the 21-position id Núclea assigns each accepted operation) through the state machine. name: Operations - description: >- Participant catalog — the acquirers, sub-acquirers, IF Domicílio (bank where the merchant receives its sales), and settlement FIs (financial institutions) that take part in card settlement. name: Participants - description: >- Card arrangements (bandeira/scheme configurations, e.g. Visa/Master/Elo) attached to a participant. name: Arrangements - description: >- Regulated transport orchestration to Núclea/SILOC (the private card clearing house that operates the SILOC settlement system) — dispatch, recovery, retransmission, and connectivity testing over managed file-transfer, message-broker, and REST. name: Connectivity - description: >- Multilateral netting clearing positions — the net amount each participant settles per STR cycle (STR = Banco Central reserves-transfer system). name: Clearing - description: >- SaaS BYOK (Bring Your Own Key) signing-key provisioning — import parameters and register the client's ICP-Brasil A1 (Brazilian PKI server certificate, 1-year validity) certificate material used to sign ASLC files; the private key never leaves the client's HSM/KMS/Vault. name: SigningKey - description: >- ASLC file intake and status — passthrough submission and processing status of the official Núclea card-settlement XML files (ASLC = Arquivo do Sistema de Liquidação de Cartões). name: Files - description: >- Read-only introspection of the embedded Núclea ASLC/RSFN (National Financial System Network) XSD schemas used to validate outbound and inbound messages. name: XSD Schemas - description: Read-only regulatory, compliance, and operational settlement reports. name: Reports - description: >- Outbound business-event webhook subscriptions and delivery management for consumers (Midaz, client ledgers, Cabine — all optional). name: Webhooks - description: >- Administrative operations — hot-reloadable runtime configuration, dead-letter-queue inspection/replay, and outbox redispatch. name: Admin paths: /v1/files: post: tags: - Files summary: Intake an ASLC file description: >- Receives an ASLC file. aslc_passthrough accepts an already-signed, opaque artifact: it is received, stored and audited WITHOUT parsing its content, and the signature outcome is recorded (never a hard reject). aslc_xml intake is not implemented in this phase (501). The uploading participantId is an explicit, validated body field; the tenant comes from the request identity, never the body. Field presence/type is validated against the schema (422); a bad participantId or non-base64 content is a coded 400. RBAC: operations:write. operationId: intakeFile requestBody: content: application/json: schema: $ref: '#/components/schemas/FileIntakeRequest' required: true responses: '202': content: application/json: schema: $ref: '#/components/schemas/FileResponse' description: Accepted default: content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Error components: schemas: FileIntakeRequest: additionalProperties: false properties: content: description: Received file bytes, base64-encoded (standard encoding). examples: - PEFTTENET0M+PC9BU0xDRE9DPg== type: string intakeMode: description: >- Intake mode: aslc_passthrough (opaque already-signed artifact) or aslc_xml (not implemented this phase, 501). examples: - aslc_passthrough type: string numCtrlEmis: description: >- Optional client correlation/reference value; written verbatim to files.control_number (max 100 chars). Not an idempotency key. examples: - CTRL-20260615-0001 type: string participantId: description: >- Uploading participant id (UUID); validated to exist, tenant-scoped. Never tenant identity. examples: - 018f8a3e-4b2c-7c1a-9e5d-2f6a1b3c4d5e type: string reasonForPassthrough: description: >- Optional free-text reason the artifact took the opaque passthrough path. examples: - client pre-signed artifact type: string receivedFilename: description: >- Optional original filename the participant sent; recorded for audit (max 255 chars). examples: - ASLC027.xml type: string required: - intakeMode - content - participantId type: object FileResponse: additionalProperties: false properties: createdAt: description: Timestamp the file row was created (RFC3339). examples: - '2026-06-15T07:50:00Z' type: string id: description: File id (UUID). examples: - 018f8a3e-4b2c-7c1a-9e5d-2f6a1b3c4d5e type: string intakeMode: description: Intake mode the file was received under. examples: - aslc_passthrough type: string operationIds: description: >- Operation ids (UUIDs) linked to this file; always a non-nil array (empty when none). items: type: string type: - array - 'null' status: description: File lifecycle status. examples: - RECEIVED type: string required: - id - intakeMode - status - operationIds - createdAt type: object Detail: additionalProperties: false properties: code: description: >- Stable, machine-readable domain error code scoped to the emitting service (format: -NNNN). examples: - ERR-0001 type: string detail: description: >- A human-readable explanation specific to this occurrence of the problem. examples: - Property foo is required but is missing. type: string errors: description: Optional list of individual error details items: $ref: '#/components/schemas/ErrorDetail' type: - array - 'null' instance: description: >- A URI reference that identifies the specific occurrence of the problem. examples: - https://example.com/error-log/abc123 format: uri type: string status: description: HTTP status code examples: - 400 format: int64 type: integer title: description: >- A short, human-readable summary of the problem type. This value should not change between occurrences of the error. examples: - Bad Request type: string type: default: about:blank description: A URI reference to human-readable documentation for the error. examples: - https://example.com/errors/example format: uri type: string type: object ErrorDetail: additionalProperties: false properties: location: description: >- Where the error occurred, e.g. 'body.items[3].tags' or 'path.thing-id' type: string message: description: Error message text type: string value: description: The value at the given location type: object securitySchemes: BearerAuth: bearerFormat: JWT description: JWT bearer token issued by the identity provider. scheme: bearer type: http ````