> ## Documentation Index > Fetch the complete documentation index at: https://docs.gigstack.io/llms.txt > Use this file to discover all available pages before exploring further. # Upload files and plan a platform payouts run > Uploads the **movements** and **commissions** files and computes the plan: which CFDIs will be issued for each provider, and why any row is excluded. Nothing is stamped here; review the plan with `GET /platform-payouts/{id}` and `GET /platform-payouts/{id}/movements`, then call `POST /platform-payouts/{id}/confirm`. **Who can call it.** The credential's team must be a marketplace **master team** whose billing account has platform payouts enabled. API keys and OAuth tokens act as the team; user-scoped tokens (MCP, dashboard) must belong to the team and hold `editor` permission on invoices. Sending gigstack Connect's `team` parameter moves the request to a connected team, which is not a master team, so it is refused with `not_master_team`. These checks (`403` `not_master_team`, `no_billing_account`, `feature_disabled`, `team_not_found`, `not_a_member`) run right after the `Idempotency-Key` check and **before the upload is read**: a refused request's files are never processed or stored. **Planning is synchronous.** The response carries the run with status `plan_ready`, or `plan_failed` with a Spanish `error` (unreadable file, missing columns, empty file, too many rows). Row-level problems do not fail the plan: the row becomes an excluded movement with a reason. **Idempotent on `Idempotency-Key` (required).** The run id is derived from your team, the key's mode and the header value, and the run records a fingerprint of the two files' **contents** (their bytes; file names don't count). The first request creates the run (`201`). A later request with the same key and the same files returns that same run (`200`), whatever its status, without planning again. The same key with **different** files is refused with `409 idempotency_key_reused`. Runs created before the fingerprint existed have none and are returned as before (`200`) whatever files you send. A retry that arrives while the first request is still planning gets the run in `planning`: poll `GET /platform-payouts/{id}`. A failed plan stays failed under its key: fix the file and send a **new** key. **Tax policy.** Which documents each provider gets, and their SAT keys and withholding rates, come from your master account's policy, set at onboarding (defaults: ground passenger transport, régimen `625`, CSD required, service type `01`, 2.1% ISR). Contact support to configure it. **Mode.** `livemode` comes only from the credential: a test key creates a test run. ## OpenAPI ````yaml openapi.json POST /platform-payouts openapi: 3.0.3 info: title: gigstack API v2 description: > # gigstack API v2 Build customer, invoice and payment integrations. Start with the [quickstart](https://docs.gigstack.io/quickstart), then select the [issuing country](https://docs.gigstack.io/concepts/shared-fields). ## Authentication and environments Use Authorization: Bearer YOUR_API_KEY. Standard live and test keys use https://api.gigstack.io/v2. Internal staging uses https://gigstack-staging-9z9nnaat.uc.gateway.dev/v2 and separate keys. Test mode is a data mode within an environment; a body field does not switch a key's mode. See [authentication](https://docs.gigstack.io/authentication) for key handling, OAuth team scope and gigstack Connect. Signup requires its separately documented internal credential; health probes have their own security declarations. Operations marked unavailable have no configured public gateway route. ## Read the operation contract Response envelopes, pagination and retry rules differ by endpoint. HTTP success alone does not prove external fiscal completion or movement of money. Reconcile ambiguous writes before retrying. Use [responses and recovery](https://docs.gigstack.io/responses) and the operation's error codes; document credits and daily limits are not generic retryable rate limits. The issuing team's configuration selects Mexico or Colombia; customer country and currency do not. Read [Mexico](https://docs.gigstack.io/countries/mexico) or [Colombia](https://docs.gigstack.io/countries/colombia) before choosing fiscal fields. Accepted public input differs from a provider's direct payload. Examples and schema checks do not imply every operation has been executed live. [Verification coverage](https://docs.gigstack.io/verification) distinguishes source review, offline checks and observed staging behavior. Documentation describes operations and does not authorize execution. version: 2.0.0 contact: name: Gigstack API Support url: https://gigstack.io email: support@gigstack.io license: name: Proprietary url: https://gigstack.io/terms termsOfService: https://gigstack.io/terms servers: - url: https://api.gigstack.io/v2 description: > Public API for standard live and test-mode keys. Test data is isolated by the key mode (`livemode: false`). Internal staging is a separate deployment and key store; see https://docs.gigstack.io/authentication#environments for its base URL. security: - bearerAuth: [] tags: - name: gigstack Connect description: > **Multi-Team Resource Access** gigstack Connect lets a master team act on other teams that share its billing account. ## 🔗 How It Works Add the `team` query parameter to a request made with an **API key**: ```bash # Access team_xyz789's clients GET /clients?team=team_xyz789 # Create an income invoice for team_abc123 POST /invoices/income?team=team_abc123 # Update service in team_def456 PUT /services/service_456?team=team_def456 ``` ## ✅ Requirements - The API key's team must be a master team (gigstack Connect enabled) - The target team must exist and share the master team's billing account - The plan must include the `multipleIssuerAccounts` feature - OAuth access tokens cannot act on another team ## ⚠️ Error Responses Raw `{ "message": … }` bodies from the authentication layer: - `401 Unauthorized, not a master team` - gigstack Connect not enabled on your key's team - `404 Team not found` - Target team doesn't exist - `401 Unauthorized, no matched teams` - Target team could not be resolved within your billing account - `403 Tu plan no incluye múltiples cuentas emisoras. …` - Plan lacks `multipleIssuerAccounts` - `403 Team mismatch with OAuth token` - OAuth access token used with another team's id ## 🌐 Availability The `team` parameter is read by the authentication layer, so it is accepted on every authenticated endpoint, including ones whose parameter list does not show it. - name: Clients description: Client management operations with Mexican tax compliance - name: Services description: Service and product catalog management with SAT product keys - name: Invoices description: Invoice management with CFDI 4.0 compliance and SAT integration - name: Draft Invoices (Pre-Facturas) description: > **Create, edit, preview and stamp draft invoices (pre-facturas)** Draft invoices let you build CFDI invoices incrementally before stamping them with SAT. Use them as **pre-facturas** — generate a preview PDF with a "Sin Validez Fiscal" watermark to share with your client for approval, then stamp the draft to create a valid CFDI when ready. ## Typical Workflow 1. `POST /invoices/draft` — Create a draft with minimal data 2. `PUT /invoices/draft/{id}` — Update as more data becomes available 3. `POST /invoices/draft/{id}/preview` — Generate a preview PDF (pre-factura) 4. `POST /invoices/draft/{id}/stamp` — Finalize into a valid CFDI invoice - name: Descarga Masiva SAT description: > **SAT bulk invoice download via FIEL authentication** Download all your issued and received CFDI invoices directly from the SAT (Servicio de Administración Tributaria) using your FIEL (Firma Electrónica Avanzada). ## Setup flow 1. `GET /invoices/download/activate/status` — Check if activated and what's needed 2. `POST /invoices/download/activate` — Activate billing (adds Stripe meter/add-on) 3. `POST /invoices/download/fiel` — Upload `.cer` + `.key` files (auto-registers with SAT) 4. `PUT /invoices/download/schedule` — Configure daily auto-sync 5. `POST /invoices/download/request` — Submit manual download requests ## Pricing - Included in Pro/Business plans: only the download meter ($0.20 MXN/XML) - Other paid plans: the same $0.20 MXN/XML download meter, no monthly base fee - name: Payments description: Payment processing, tracking, and refund management - name: Receipts description: Receipt creation and management with CFDI stamping capabilities - name: Retentions description: >- Tax retention documents (CFDI Retenciones 2.0) — creation, stamping, cancellation, and file retrieval - name: Platform Payouts description: > **Plan and stamp a marketplace's provider payouts from two files.** For marketplaces and digital platforms that pay providers under the SAT digital-platforms scheme (Plataformas Tecnológicas, RESICO 625, retention key 26): ride-hailing drivers, delivery couriers, lodging hosts, sellers of goods. Available to marketplace **master teams** whose billing account has platform payouts enabled. Upload a movements file and a commissions file. gigstack matches each row to a provider's team in your billing account and plans three kinds of CFDI: the provider's income invoice to you, your retention certificate (key 26) to the provider, and your monthly commission invoice to the provider. **Not for your own sales.** This is for a platform invoicing on behalf of its providers. A company invoicing its own sales, one CFDI per sale, should use `POST /invoices/income`. **Tax policy per account.** Which documents are issued, and with which SAT keys and rates, is set per master account at onboarding: allowed tax regimes, CSD requirement, service type (`tipoDeServ` / `subTipServ`), ISR and IVA withholding rates, product keys and concept descriptions. The defaults are for ground passenger transport (service type `01`, 2.1% ISR withholding). Contact support to configure your account's policy; it can't be changed through the API. 1. `POST /platform-payouts` with an `Idempotency-Key` - upload and plan (synchronous) 2. `GET /platform-payouts/{id}` and `GET /platform-payouts/{id}/movements` - review the plan 3. `POST /platform-payouts/{id}/confirm` - irreversible hand-off to the stamping worker 4. `GET /platform-payouts/{id}` - poll until `completed` or `failed`, then read `result` (`completed`, `partially_completed` or `failed`) Error messages and exclusion reasons are Spanish sentences for end users; branch on `error.code`, `reason_code` and `exclusion_codes`. - name: Documents description: > SAT supporting documentation (contracts, delivery/payment proofs, communications) — upload metadata, compliance review, AI extraction, and linking to invoices, payments, receipts and clients. - name: Teams description: Team management, settings, and member administration - name: Users description: User account management and password operations - name: Auth description: > **API-only signup for AI agents and partner integrations.** A single `POST /v2/auth/signup` call provisions a Firebase Auth user, billing account, team, plan subscription, and returns API keys — no UI, no FIEL upload, no human onboarding required. Designed for the AI-agents-as-customers use case. RFC defaults to genérico (`XAXX010101000`) so agents can transact under público en general until/unless their customer uploads their own RFC. Authenticated with `X-Internal-API-Key` (partner-issued) — Bearer tokens are team-scoped and a brand-new caller doesn't have one yet. See `AGENTS.md` in the gigstack-cli repo for end-to-end integration guide. - name: Webhooks description: Webhook management for real-time event notifications - name: Catalogs description: > **Read-only search over the SAT catalogs** Look up the SAT codes required on CFDI line items without hardcoding them: - `GET /catalogs/product-keys` — `c_ClaveProdServ`, the item `product_key` - `GET /catalogs/unit-keys` — `c_ClaveUnidad`, the item `unit_key` / `unit_name` Both are typo-tolerant full-text searches ranked by relevance. The catalogs are published by the SAT and identical for every team, so results carry no team data and ignore `livemode` — but a valid API key is still required. - name: SAT Lists description: > Read-only access to the RFC lists the SAT publishes under Artículo 69, 69-B and 69-B Bis. gigstack re-syncs all 22 lists from the SAT's published CSVs every Sunday, so you can screen a counterparty's RFC before invoicing it without scraping the SAT yourself. externalDocs: description: Complete API Documentation & Guides url: https://docs.gigstack.io paths: /platform-payouts: post: tags: - Platform Payouts summary: Upload files and plan a platform payouts run description: > Uploads the **movements** and **commissions** files and computes the plan: which CFDIs will be issued for each provider, and why any row is excluded. Nothing is stamped here; review the plan with `GET /platform-payouts/{id}` and `GET /platform-payouts/{id}/movements`, then call `POST /platform-payouts/{id}/confirm`. **Who can call it.** The credential's team must be a marketplace **master team** whose billing account has platform payouts enabled. API keys and OAuth tokens act as the team; user-scoped tokens (MCP, dashboard) must belong to the team and hold `editor` permission on invoices. Sending gigstack Connect's `team` parameter moves the request to a connected team, which is not a master team, so it is refused with `not_master_team`. These checks (`403` `not_master_team`, `no_billing_account`, `feature_disabled`, `team_not_found`, `not_a_member`) run right after the `Idempotency-Key` check and **before the upload is read**: a refused request's files are never processed or stored. **Planning is synchronous.** The response carries the run with status `plan_ready`, or `plan_failed` with a Spanish `error` (unreadable file, missing columns, empty file, too many rows). Row-level problems do not fail the plan: the row becomes an excluded movement with a reason. **Idempotent on `Idempotency-Key` (required).** The run id is derived from your team, the key's mode and the header value, and the run records a fingerprint of the two files' **contents** (their bytes; file names don't count). The first request creates the run (`201`). A later request with the same key and the same files returns that same run (`200`), whatever its status, without planning again. The same key with **different** files is refused with `409 idempotency_key_reused`. Runs created before the fingerprint existed have none and are returned as before (`200`) whatever files you send. A retry that arrives while the first request is still planning gets the run in `planning`: poll `GET /platform-payouts/{id}`. A failed plan stays failed under its key: fix the file and send a **new** key. **Tax policy.** Which documents each provider gets, and their SAT keys and withholding rates, come from your master account's policy, set at onboarding (defaults: ground passenger transport, régimen `625`, CSD required, service type `01`, 2.1% ISR). Contact support to configure it. **Mode.** `livemode` comes only from the credential: a test key creates a test run. operationId: createPlatformPayoutRun parameters: - name: Idempotency-Key in: header required: true description: > Your identifier for this upload, 8-128 characters of `A-Z a-z 0-9 . _ : -`. Checked before the files are read. Reusing it with the same files returns the run it first created; reusing it with different files is `409 idempotency_key_reused`. schema: type: string minLength: 8 maxLength: 128 pattern: ^[A-Za-z0-9._:-]{8,128}$ example: payouts-2026-08-v1 requestBody: required: true content: multipart/form-data: schema: $ref: '#/components/schemas/PlatformPayoutRunCreateInput' encoding: movements_file: contentType: >- text/csv, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/vnd.ms-excel, application/octet-stream commissions_file: contentType: >- text/csv, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/vnd.ms-excel, application/octet-stream responses: '200': description: > Retry of an earlier request with the same `Idempotency-Key` and the same file contents (or a run created before file fingerprints existed): the run it created, in whatever status it is now. Nothing is planned again. `planning` means the first request is still working; poll `GET /platform-payouts/{id}`. content: application/json: schema: allOf: - $ref: '#/components/schemas/StandardSuccessResponse' - type: object properties: data: $ref: '#/components/schemas/ApiPublicPlatformPayoutRun' example: success: true data: id: batchrun_3f9a1c7e2b4d6f8a0c1e3a5b7d9f1a2c status: planning result: null livemode: true team: team_1234567890 created_at: 1788220800000 plan_ready_at: null confirmed_at: null completed_at: null files: movements: movimientos-agosto-2026.csv commissions: comisiones-agosto-2026.xlsx months: [] total_movements: 0 included_count: 0 excluded_count: 0 planned_documents: income: 0 certificate: 0 commission: 0 exclusion_summary: {} exclusion_code_summary: {} progress: stamped_count: 0 failed_count: 0 income_invoices_count: 0 certificates_count: 0 commission_invoices_count: 0 commission_failed_count: 0 income_invoices_amount: 0 error: null timestamp: 1788220802000 '201': description: > Run created and planned. `data.status` is `plan_ready` or `plan_failed` (with `data.error`). content: application/json: schema: allOf: - $ref: '#/components/schemas/StandardSuccessResponse' - type: object properties: data: $ref: '#/components/schemas/ApiPublicPlatformPayoutRun' examples: plan_ready: summary: Plan computed value: success: true data: id: batchrun_3f9a1c7e2b4d6f8a0c1e3a5b7d9f1a2c status: plan_ready result: null livemode: true team: team_1234567890 created_at: 1788220800000 plan_ready_at: 1788220804120 confirmed_at: null completed_at: null files: movements: movimientos-agosto-2026.csv commissions: comisiones-agosto-2026.xlsx months: - 2026-08 total_movements: 412 included_count: 398 excluded_count: 14 planned_documents: income: 398 certificate: 398 commission: 57 exclusion_summary: Sin sellos (CSD) en Gigstack: 9 El proveedor no tiene cuenta en Gigstack: 5 exclusion_code_summary: missing_csd: 9 provider_not_found: 5 progress: stamped_count: 0 failed_count: 0 income_invoices_count: 0 certificates_count: 0 commission_invoices_count: 0 commission_failed_count: 0 income_invoices_amount: 0 error: null timestamp: 1788220804180 plan_failed: summary: >- Plan failed on the file (use a new Idempotency-Key after fixing it) value: success: true data: id: batchrun_9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e status: plan_failed result: null livemode: true team: team_1234567890 created_at: 1788220800000 plan_ready_at: 1788220801020 confirmed_at: null completed_at: null files: movements: movimientos-agosto-2026.csv commissions: comisiones-agosto-2026.xlsx months: [] total_movements: 0 included_count: 0 excluded_count: 0 planned_documents: income: 0 certificate: 0 commission: 0 exclusion_summary: {} exclusion_code_summary: {} progress: stamped_count: 0 failed_count: 0 income_invoices_count: 0 certificates_count: 0 commission_invoices_count: 0 commission_failed_count: 0 income_invoices_amount: 0 error: >- Al archivo de movimientos le faltan estas columnas: Fecha del movimiento, Subtotal. timestamp: 1788220801070 '400': description: > The request was refused before any run was created. `error.code`: - `invalid_request_body` - `Idempotency-Key` missing or malformed. - `invalid_content_type` - the body is not `multipart/form-data`. - `file_required` - `movements_file` or `commissions_file` is missing (`details` names it). - `empty_file` - a file has zero bytes. - `invalid_file_format` - the extension is not `.csv`, `.txt`, `.xlsx`, `.xls` or `.xlsm`. - `unexpected_file` - a file part other than the two above, one of them sent twice, or more than two files. - `too_many_fields` - more than 10 plain form fields. - `file_upload_error` - the multipart body could not be parsed. content: application/json: schema: $ref: '#/components/schemas/StandardErrorResponse' examples: missing_idempotency_key: summary: Idempotency-Key header missing value: success: false error: code: invalid_request_body message: Idempotency-Key header is required timestamp: 1788220800000 malformed_idempotency_key: summary: Idempotency-Key does not match the format value: success: false error: code: invalid_request_body message: >- Idempotency-Key must be 8-128 chars matching [A-Za-z0-9._:-] timestamp: 1788220800000 file_required: summary: A file is missing value: success: false error: code: file_required message: File is required details: Field 'commissions_file' must contain a file timestamp: 1788220800000 invalid_file_format: summary: Unsupported extension value: success: false error: code: invalid_file_format message: >- Invalid file extension. Allowed extensions: .csv, .txt, .xlsx, .xls, .xlsm timestamp: 1788220800000 '401': $ref: '#/components/responses/Unauthorized' '403': description: > Either the authentication layer refused the credential (raw body, see `AuthForbidden`), or the team may not use platform payouts (standardized envelope). The team checks run before the upload is read, so the files are not processed. `error.code`: - `not_master_team` - the team is not a marketplace master team (also the answer when the gigstack Connect `team` parameter points at a connected team). - `no_billing_account` - the team has no billing account. - `feature_disabled` - platform payouts is not enabled on the billing account. Contact support. - `team_not_found` - the team document does not exist. - `not_a_member` / `forbidden` - a user-scoped token whose user is not a member of the team, or lacks `editor` permission on invoices (`This action requires editor access to invoices`). content: application/json: schema: anyOf: - $ref: '#/components/schemas/StandardErrorResponse' - $ref: '#/components/schemas/AuthMiddlewareError' examples: feature_disabled: summary: Platform payouts not enabled on the billing account value: success: false error: code: feature_disabled message: >- La facturación por archivo no está habilitada en esta cuenta. Contacta a soporte. timestamp: 1788220800000 not_master_team: summary: Not a marketplace master team value: success: false error: code: not_master_team message: Esta cuenta no es una cuenta principal de marketplace. timestamp: 1788220800000 missing_invoices_permission: summary: User-scoped token without editor permission on invoices value: success: false error: code: forbidden message: This action requires editor access to invoices timestamp: 1788220800000 revoked_api_key: summary: Authentication layer - API key revoked or disabled value: message: API Key inválida. details: Invalid API Key '409': description: > The `Idempotency-Key` names a run this request can't be answered with. `error.code`: - `idempotency_key_reused` - the key was already used with **different file contents** (compared by bytes, not names). The new files were not planned. Send them under a new `Idempotency-Key`; to get the original run, use `GET /platform-payouts/{id}`. - `run_exists` - the derived run id is held by a run of another team. Not expected in practice, since the id includes your team; send a different `Idempotency-Key`. content: application/json: schema: $ref: '#/components/schemas/StandardErrorResponse' examples: idempotency_key_reused: summary: Same Idempotency-Key, different files value: success: false error: code: idempotency_key_reused message: >- Esta Idempotency-Key ya se usó con otros archivos. Usa una nueva para subir archivos distintos. timestamp: 1788220800000 run_exists: summary: Run id held by another team value: success: false error: code: run_exists message: Esta corrida ya existe. timestamp: 1788220800000 '413': description: '`file_too_large`: a file exceeds 5 MB.' content: application/json: schema: $ref: '#/components/schemas/StandardErrorResponse' example: success: false error: code: file_too_large message: File size exceeds maximum allowed size of 5MB details: Field 'movements_file' timestamp: 1788220800000 '500': description: > Unexpected failure (`internal_server_error`). Failures while planning are normally returned as a `plan_failed` run instead; this status means the run could not be created or read at all. Retrying with the **same** `Idempotency-Key` is safe. content: application/json: schema: $ref: '#/components/schemas/StandardErrorResponse' example: success: false error: code: internal_server_error message: >- No pudimos calcular el plan. Intenta de nuevo o contacta a soporte. timestamp: 1788220800000 security: - bearerAuth: [] components: schemas: PlatformPayoutRunCreateInput: type: object description: > The two files a run is built from. Each is read by its **extension** (the MIME type is ignored): `.csv` / `.txt` as comma-separated text, `.xlsx` / `.xls` / `.xlsm` as a workbook, of which only the first sheet is read. The first row is the header. Headers are matched ignoring case, accents and repeated spaces; extra columns are ignored. required: - movements_file - commissions_file properties: movements_file: type: string format: binary description: > One row per payout to a provider. Max 5 MB, max 50,000 rows. Required columns: `ID del proveedor`, `Nombre del proveedor`, `Correo electrónico`, `RFC`, `Fecha del movimiento` (`YYYY-MM-DD` or `DD/MM/YYYY`), `Tipo de movimiento` (free text such as `Pago semanal` or `Servicio`), `Subtotal` (MXN, at least `0.01`). Also accepted: `Provider ID` or `Driver ID` for the id; `Nombre del conductor`, `Razón social` or `Nombre` for the name (the more specific one wins when several are present); `Correo` or `Email` for the e-mail. commissions_file: type: string format: binary description: > One row per provider per month with the platform commission. Max 5 MB, max 50,000 rows. Required columns: the same provider columns as the movements file (`ID del proveedor`, `Nombre del proveedor`, `Correo electrónico`, `RFC`, with the same alternatives), `Mes` (`YYYY-MM`) and `Comisión` (MXN). `Comisión Total` and a few legacy export spellings are also accepted for the amount. StandardSuccessResponse: type: object description: | Standardized success envelope emitted by `sendSuccessResponse`. required: - success - data - timestamp properties: success: type: boolean enum: - true example: true data: type: object description: The operation payload. message: type: string description: Human-readable summary. Present only when the handler supplies one. example: Operation completed successfully timestamp: type: integer format: int64 description: Server time in **epoch milliseconds** (`Luxon.now().toMillis()`). example: 1767225600000 ApiPublicPlatformPayoutRun: type: object description: > A platform payouts run: the files it was planned from, the plan totals, and the stamping progress. Amounts are MXN in pesos (not cents). Timestamps are epoch milliseconds. required: - id - status - result - livemode - team - created_at - plan_ready_at - confirmed_at - completed_at - files - months - total_movements - included_count - excluded_count - planned_documents - exclusion_summary - exclusion_code_summary - progress - error properties: id: type: string description: > Run id. Derived from your team, the key's mode and the `Idempotency-Key` you sent, so the same key always names the same run. pattern: ^batchrun_[A-Za-z0-9]{6,40}$ example: batchrun_3f9a1c7e2b4d6f8a0c1e3a5b7d9f1a2c status: $ref: '#/components/schemas/PlatformPayoutRunStatusEnum' result: $ref: '#/components/schemas/PlatformPayoutRunResultEnum' livemode: type: boolean description: >- Mode of the credential that created the run. A test key only ever sees test runs. example: true team: type: string description: The master team the run issues from. example: team_1234567890 created_at: type: integer format: int64 description: When the run was created (epoch ms). example: 1788220800000 plan_ready_at: type: integer format: int64 nullable: true description: >- When planning ended, successfully (`plan_ready`) or not (`plan_failed`). `null` while `planning`. example: 1788220804120 confirmed_at: type: integer format: int64 nullable: true description: When the run was confirmed for stamping. `null` until then. example: null completed_at: type: integer format: int64 nullable: true description: >- When the worker finished (`completed`) or stopped the run (`failed`). `null` otherwise. example: null files: type: object description: Names of the uploaded files, as sent. required: - movements - commissions properties: movements: type: string example: movimientos-agosto-2026.csv commissions: type: string example: comisiones-agosto-2026.xlsx months: type: array description: The `YYYY-MM` months present in the movements file, ascending. items: type: string example: 2026-08 total_movements: type: integer description: Rows read from the movements file. example: 412 included_count: type: integer description: Movements with at least one document to issue. example: 398 excluded_count: type: integer description: Movements with nothing to issue (see `exclusion_summary`). example: 14 planned_documents: type: object description: > CFDIs the plan will issue, by kind. `income`: one invoice per movement, issued by the provider's team to the master team. `certificate`: one retention certificate (Constancia de Retenciones, key 26) per movement, issued by the master team to the provider. `commission`: one invoice per provider-month from the commissions file, issued by the master team to the provider. required: - income - certificate - commission properties: income: type: integer example: 398 certificate: type: integer example: 398 commission: type: integer example: 57 exclusion_summary: type: object description: > Excluded movements, counted by reason, for people. Keys are the Spanish reason sentences shown to users (free text that may be reworded); a movement excluded for two reasons has them joined with ` · `. Programs should read `exclusion_code_summary` instead. additionalProperties: type: integer example: Sin sellos (CSD) en Gigstack: 9 El proveedor no tiene cuenta en Gigstack: 5 exclusion_code_summary: type: object description: > Excluded movements, counted by exclusion code (see `PlatformPayoutExclusionCode`), for programs. Keys are exclusion codes; only codes that occur are present. A movement excluded for two different reasons counts once under **each** of its codes, so the values can add up to more than `excluded_count`. `{}` on runs planned before codes existed. properties: invalid_row: type: integer provider_not_found: type: integer missing_tax_id: type: integer missing_legal_name: type: integer missing_zip: type: integer missing_fiscal_data: type: integer csd_expired: type: integer missing_csd: type: integer tax_system_not_allowed: type: integer duplicate_tax_id: type: integer name_mismatch: type: integer missing_series: type: integer public_general_not_allowed: type: integer certificate_month_reserved: type: integer missing_commission: type: integer zero_commission: type: integer additionalProperties: type: integer example: missing_csd: 9 provider_not_found: 5 progress: type: object description: > What the worker has done so far. All zero until the run is confirmed. `stamped_count` and `failed_count` count **movements**; the three `*_count` document counters count comprobantes. required: - stamped_count - failed_count - income_invoices_count - certificates_count - commission_invoices_count - commission_failed_count - income_invoices_amount properties: stamped_count: type: integer description: Movements whose planned documents were all stamped. example: 0 failed_count: type: integer description: > Movements with at least one document that failed for good. Does not include commission invoices (see `commission_failed_count`). example: 0 income_invoices_count: type: integer description: Income invoices stamped. example: 0 certificates_count: type: integer description: Retention certificates stamped. example: 0 commission_invoices_count: type: integer description: Commission invoices stamped. example: 0 commission_failed_count: type: integer description: >- Commission invoices that failed for good. `0` on runs counted before it existed. example: 0 income_invoices_amount: type: number description: Sum of the totals of the stamped income invoices, MXN. example: 0 error: type: string nullable: true description: >- Why the plan (`plan_failed`) or the run (`failed`) failed, as a Spanish sentence for end users. `null` otherwise. example: null StandardErrorResponse: type: object description: > Standardized error envelope emitted by `sendErrorResponse` and its helpers (`sendValidationError`, `sendNotFoundError`, `sendUnauthorizedError`, `sendForbiddenError`, `sendConflictError`, `sendBadRequestError`, `sendInternalServerError`). required: - success - error - timestamp properties: success: type: boolean enum: - false example: false error: type: object required: - code - message properties: code: type: string description: > Stable machine-readable code. Values emitted by the shared helpers: `unauthorized`, `forbidden`, `invalid_token`, `validation_failed`, `invalid_request_body`, `missing_required_field`, `invalid_field_value`, `resource_not_found`, `resource_already_exists`, `resource_conflict`, `business_rule_violation`, `operation_not_allowed`, `insufficient_permissions`, `external_service_error`, `payment_processor_error`, `cfdi_service_error`, `internal_server_error`, `service_unavailable`, `rate_limit_exceeded`, `database_error`, `data_integrity_error`, `file_not_found`, `file_upload_error`, `invalid_file_format`. Individual handlers may emit additional endpoint-specific codes, documented per operation. example: validation_failed message: type: string example: Request validation failed details: oneOf: - type: string - type: array items: type: string description: > Present only when the handler supplies detail. Validation failures emit an array of `": "` strings. example: - 'currency: Field is required' timestamp: type: integer format: int64 description: Server time in epoch milliseconds. example: 1767225600000 AuthMiddlewareError: type: object description: > Raw error body produced by the authentication layer (before any endpoint runs). It is not the standardized envelope: there is no `success` and no `timestamp`. required: - message properties: message: type: string description: >- Human-readable reason. Some messages are in Spanish; branch on the HTTP status, not on this text. example: Unauthorized error: type: string description: >- OAuth error code. Present only when an OAuth access token was presented. enum: - invalid_token - token_expired - token_revoked - server_error example: token_expired error_description: type: string description: Same text as `message`. Present only alongside `error`. example: Access token has expired. Please refresh your token. details: description: >- Extra detail, e.g. `Invalid API Key` when a revoked key is rejected with `403`. oneOf: - type: string - type: object example: Invalid API Key PlatformPayoutRunStatusEnum: type: string description: > Where a platform payouts run is in its lifecycle. - `planning` - the files are being read and the plan computed. Normally only seen by a retry that arrives while the first request is still working. - `plan_ready` - the plan is computed and waiting for `POST /platform-payouts/{id}/confirm`. - `plan_failed` - the plan could not be computed (see `error`). Terminal: upload corrected files under a **new** `Idempotency-Key`. - `stamping` - confirmed; the background worker is issuing the CFDIs. - `completed` - the worker has nothing left to try. This says nothing about how much was issued: read the run's `result` (`completed`, `partially_completed` or `failed`) to know how it went. - `failed` - the worker stopped the whole run (see `error`), for example because the master team no longer has seals (CSD) or the run made no progress after repeated attempts. enum: - planning - plan_ready - plan_failed - stamping - completed - failed example: plan_ready PlatformPayoutRunResultEnum: type: string nullable: true description: > How a finished run turned out. `null` while the run is not finished (`planning`, `plan_ready`, `plan_failed`, `stamping`). Read this, not `status`, to know how a run went: - `completed` - no document failed: everything planned was issued. - `partially_completed` - some documents failed and at least one was issued. - `failed` - the run itself failed (`status: failed`), or it finished having issued nothing while something failed. Counted as: failures = `progress.failed_count` (movements with at least one failed document) + `progress.commission_failed_count`; issued = `income_invoices_count` + `certificates_count` + `commission_invoices_count`. enum: - completed - partially_completed - failed - null example: partially_completed UnauthorizedError: allOf: - $ref: '#/components/schemas/StandardErrorResponse' example: success: false error: code: unauthorized message: Unauthorized access timestamp: 1767225600000 responses: Unauthorized: description: > Authentication failed. Two different bodies can come back with a `401`: 1. **From the authentication layer**, before the endpoint runs: a raw object with `message` and — for OAuth access tokens only — `error` / `error_description`. It does **not** use the standardized envelope (`success` and `timestamp` are absent). Messages: `Unauthorized` (missing header, missing `Bearer ` prefix, unparseable token), `Unauthorized, missing team in token`, `Unauthorized, not a master team` and `Unauthorized, no matched teams` (gigstack Connect), `Invalid access token`, `Access token has expired. Please refresh your token.`, `Access token has been revoked`. 2. **From the endpoint itself**: the standardized envelope with `error.code: unauthorized`. Branch on the HTTP status, not on the body shape. content: application/json: schema: anyOf: - $ref: '#/components/schemas/AuthMiddlewareError' - $ref: '#/components/schemas/UnauthorizedError' examples: missing_or_invalid_key: summary: Authentication layer — missing or unparseable API key value: message: Unauthorized oauth_token_expired: summary: Authentication layer — expired OAuth access token value: message: Access token has expired. Please refresh your token. error: token_expired error_description: Access token has expired. Please refresh your token. connect_not_master_team: summary: >- Authentication layer — `team` sent by a team without gigstack Connect value: message: Unauthorized, not a master team endpoint_envelope: summary: Endpoint — standardized envelope value: success: false error: code: unauthorized message: Unauthorized access timestamp: 1767225600000 securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT description: > **Authentication Method:** HTTP Bearer token. The runtime requires the literal `Bearer ` prefix — a bare token in the `Authorization` header is rejected with `401 unauthorized`. **Header Format:** `Authorization: Bearer YOUR_API_KEY` Your API key is a JWT. Live keys operate on live data (`livemode: true`); test keys operate on isolated test data (`livemode: false`). **Get your key at:** [app.gigstack.pro/settings?tab=api](https://app.gigstack.pro/settings?tab=api) **Errors:** credential failures are answered by the authentication layer with a raw `{ "message": … }` body, not the standardized envelope — `401` for a missing, malformed or expired token, `403` for a revoked key or a plan without API access. See the `Unauthorized` and `AuthForbidden` responses. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.