> ## 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. # Update payment > Update a payment. The endpoint supports modifying the `description` of items, attaching `automation_type` to a payment that has no automations, and patching the embedded `client` (with the change propagated to the `/clients/{id}` master record). The body must include at least one of `items`, `automation_type` or `client`. **gigstack Connect:** Update other teams' payments using the `team` parameter. ## What can be updated - **Item description**: For each entry in `items`, the item is matched by `id` inside the payment and its `description` is replaced. Any other field on the item (taxes, discounts, quantity, unit_price, etc.) is rejected by validation. Item totals, taxes and `itemsAmounts` are not recalculated. - **Automations**: `automation_type` is only accepted when the payment has no existing automations. If the payment already has automations, the request returns 400. The same enum values used by `POST /payments/register` apply (`pue_invoice`, `ppd_invoice_and_complement`, `none`). - **Client**: The `client` object accepts a partial patch (`name`, `company`, `phone`, `email`, `bcc`, `metadata`, `legal_name`, `tax_id`, `use`, `tax_system`, `address`). The client `id` cannot be modified. Each provided field is written both to the `client` embedded in the payment and to the `/clients/{id}` master document via a partial merge. Fiscal/SAT validation is not re-run from this endpoint — call `PUT /clients/{id}` if full re-validation is needed. ## Trigger re-fire for already succeeded payments When non-empty automations are added (i.e. `automation_type` is `pue_invoice` or `ppd_invoice_and_complement`) and the payment is already `succeeded`, the endpoint performs a second write that sets `status` to `succeeded_` so that the downstream automation trigger (which fires on transitions into `succeeded`) can re-fire on a subsequent flip back to `succeeded`. ## Allowed payment statuses The endpoint accepts updates regardless of payment status (including `succeeded` and `cancelled`) so descriptions can be corrected after the fact. Note that this endpoint does not re-issue or modify any CFDI already linked to the payment. ## OpenAPI ````yaml openapi.json PUT /payments/{id} 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: /payments/{id}: put: tags: - Payments summary: Update payment description: > Update a payment. The endpoint supports modifying the `description` of items, attaching `automation_type` to a payment that has no automations, and patching the embedded `client` (with the change propagated to the `/clients/{id}` master record). The body must include at least one of `items`, `automation_type` or `client`. **gigstack Connect:** Update other teams' payments using the `team` parameter. ## What can be updated - **Item description**: For each entry in `items`, the item is matched by `id` inside the payment and its `description` is replaced. Any other field on the item (taxes, discounts, quantity, unit_price, etc.) is rejected by validation. Item totals, taxes and `itemsAmounts` are not recalculated. - **Automations**: `automation_type` is only accepted when the payment has no existing automations. If the payment already has automations, the request returns 400. The same enum values used by `POST /payments/register` apply (`pue_invoice`, `ppd_invoice_and_complement`, `none`). - **Client**: The `client` object accepts a partial patch (`name`, `company`, `phone`, `email`, `bcc`, `metadata`, `legal_name`, `tax_id`, `use`, `tax_system`, `address`). The client `id` cannot be modified. Each provided field is written both to the `client` embedded in the payment and to the `/clients/{id}` master document via a partial merge. Fiscal/SAT validation is not re-run from this endpoint — call `PUT /clients/{id}` if full re-validation is needed. ## Trigger re-fire for already succeeded payments When non-empty automations are added (i.e. `automation_type` is `pue_invoice` or `ppd_invoice_and_complement`) and the payment is already `succeeded`, the endpoint performs a second write that sets `status` to `succeeded_` so that the downstream automation trigger (which fires on transitions into `succeeded`) can re-fire on a subsequent flip back to `succeeded`. ## Allowed payment statuses The endpoint accepts updates regardless of payment status (including `succeeded` and `cancelled`) so descriptions can be corrected after the fact. Note that this endpoint does not re-issue or modify any CFDI already linked to the payment. operationId: updatePaymentsById parameters: - $ref: '#/components/parameters/TeamParameter' - name: id in: path required: true schema: type: string example: payment_1234567890 requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/UpdatePaymentInput' examples: update_item_description: summary: Fix the description of one item value: items: - id: service_1234567890 description: Servicio de consultoría profesional - corregido add_automation: summary: Attach a PUE invoice automation to a payment that had none value: automation_type: pue_invoice update_both: summary: Update item description and add automations in a single call value: items: - id: service_1234567890 description: Servicio de consultoría profesional - corregido automation_type: pue_invoice update_client_email: summary: Update only the email of the client value: client: email: nuevo.correo@ejemplo.com update_client_fiscal: summary: Update fiscal info and address of the client value: client: legal_name: JUAN PEREZ GARCIA tax_id: PEGJ800101ABC tax_system: '601' use: G03 address: country: MEX zip: '06600' state: CDMX responses: '200': description: Payment updated successfully content: application/json: schema: $ref: '#/components/schemas/StandardSuccessResponse' example: success: true data: id: payment_1234567890 client: id: client_1234567890 name: ESCUELA KEMPER URGATE legal_name: ESCUELA KEMPER URGATE email: contabilidad@ejemplo.com bcc: [] phone: '+524421234567' tax_id: EKU9003173C9 tax_system: '601' use: G03 address: street: Av. Constituyentes exterior: '1000' neighborhood: Centro city: Querétaro state: QRO zip: '76000' country: MEX is_valid: true efos: is_valid: true metadata: {} livemode: true from: api owner: user_1234567890 team: team_1234567890 created_at: 1767225600000 emails: - contabilidad@ejemplo.com currency: MXN allowed_payment_methods: - card - bank exchange_rate: 1 items: - id: service_1234567890 description: Servicios de consultoría profesional quantity: 1 unit_price: 1000 product_key: '80141503' unit_key: E48 unit_name: Unidad de servicio taxes: - type: IVA rate: 0.16 factor: Tasa withholding: false team: team_1234567890 created_at: 1767225600000 from: api metadata: {} team: team_1234567890 idempotency_key: payment-2026-0001 from: api invoices: - B0C3E4F2-1A2B-4C5D-9E8F-0123456789AB livemode: true owner: user_1234567890 payment_form: '03' payments: [] receipts: [] refunds: [] short_url: https://gigstack.xyz/Xk3mP9 success_url: null status: succeeded total: 1160 total_refunded: 0 subtotal: 1000 taxes: 160 discount: 0 withholding_taxes: 0 created_at: 1767225600000 succeeded_at: 1767225900000 payment_processor: api message: Payment updated successfully timestamp: 1767225600000 '400': description: > Validation error. Possible causes: empty body, item id not found in payment, payment already has automations, or unexpected fields on items. content: application/json: schema: $ref: '#/components/schemas/ValidationErrorResponse' '403': description: The authenticated team does not own this payment content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '404': description: Payment not found content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - bearerAuth: [] components: parameters: TeamParameter: name: team in: query required: false schema: type: string description: > **gigstack Connect:** Target team ID for multi-team access. Requires gigstack Connect enabled on your team and shared billing account. Also requires the `multipleIssuerAccounts` feature on your plan. Requests targeting a team other than the one your API key belongs to return `403` without it. Only API keys can use it: an OAuth access token sent with another team's id is rejected with `403 Team mismatch with OAuth token`. **Optional — omit it entirely** unless you are acting on another team. It deliberately carries no example value so generated snippets do not emit `?team=undefined`; when the parameter is absent, the team is derived from your API key. **Example:** `?team=team_xyz789` schemas: UpdatePaymentInput: description: > Body for the PUT /payments/{id} endpoint. At least one of `items`, `automation_type` or `client` must be present. - `items`: Update the `description` of one or more items in the payment, matched by item `id`. Only `description` can be modified — taxes, discounts, quantities and unit prices are immutable from this endpoint and any other field is rejected. - `automation_type`: Add automations to a payment that does not have any. If the payment already has automations, the request is rejected with 400. When non-empty automations are added and the payment status is `succeeded`, the status is flipped to `succeeded_` after the update so the automation trigger can re-fire. - `client`: Update fields of the client embedded in the payment (name, email, fiscal info, address, etc.). The client `id` cannot be changed. Any provided field is also written to the matching `/clients/{id}` document via a partial merge, so the client master record stays in sync with the payment. Fiscal/SAT validation is **not** re-run from this endpoint — use `PUT /clients/{id}` if you need that. type: object additionalProperties: false properties: items: description: >- List of items to update. Only the `description` of each item can be modified. type: array items: type: object additionalProperties: false required: - id - description properties: id: description: Item id within the payment example: service_1234567890 type: string minLength: 1 description: description: New description for the item example: Servicio de consultoría profesional - corregido type: string minLength: 1 nullable: true minItems: 1 automation_type: description: >- Automation to attach to the payment. Only allowed if the payment currently has no automations. example: pue_invoice type: string enum: - pue_invoice - ppd_invoice_and_complement - none - null nullable: true invoice_config: type: object additionalProperties: false properties: serie: type: string nullable: true folio: type: number nullable: true date: type: number nullable: true global: type: object additionalProperties: false properties: year: type: number nullable: true months: type: string nullable: true periodicity: type: string nullable: true nullable: true validUntil: type: number nullable: true nullable: true client: description: > Partial update for the client embedded in the payment. Only the listed fields can be modified — the client `id` cannot be changed. Each provided field is propagated to the `/clients/{id}` master document via a partial merge. type: object additionalProperties: false properties: name: example: Juan Pérez García type: string nullable: true company: example: Acme S.A. de C.V. type: string nullable: true phone: example: '+525555555555' type: string nullable: true email: example: juan.perez@ejemplo.com type: string nullable: true format: email bcc: type: array nullable: true items: type: string metadata: type: object additionalProperties: true properties: {} nullable: true legal_name: example: JUAN PEREZ GARCIA type: string nullable: true tax_id: description: >- Mexican SAT RFC. Mirrored to the legacy `rfc` field on the client document. example: PEGJ800101ABC type: string nullable: true use: example: G03 type: string nullable: true tax_system: example: '601' type: string nullable: true address: description: >- Partial address update. Only fields present in the request are merged onto the existing address; absent fields are kept as-is. type: object additionalProperties: false properties: country: example: MEX type: string nullable: true maxLength: 3 street: type: string nullable: true zip: type: string nullable: true city: type: string nullable: true state: type: string nullable: true exterior: type: string nullable: true interior: type: string nullable: true municipality: type: string nullable: true neighborhood: type: string nullable: true nullable: true nullable: true 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 ValidationErrorResponse: allOf: - $ref: '#/components/schemas/StandardErrorResponse' description: > Body validation failure. Unknown top-level keys are rejected — the validator runs in strict allowlist mode (`allowUnknown: false`), so a field not declared in the request schema produces an `unexpected_key` detail rather than being ignored. example: success: false error: code: validation_failed message: Request validation failed details: - 'currency: Field is required' - 'client_id: Unexpected field' timestamp: 1767225600000 ErrorResponse: allOf: - $ref: '#/components/schemas/StandardErrorResponse' description: Standardized error envelope. example: success: false error: code: invalid_request_body message: An error occurred timestamp: 1767225600000 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 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.