> ## 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.

# Stamp receipt

> Convert a receipt into a CFDI invoice by stamping it with SAT.

Only receipts with `status: pending` can be stamped. A receipt that already has
entries in `invoices[]` is returned as-is with a `200` and no new CFDI; any other
non-pending receipt (a cancelled one is stored as `completed`) is rejected with a
`409`.

**Stamp Options:**
- `client`: Stamp to the associated client
- `general_public_national`: Stamp to Mexican general public
- `general_public_foreign`: Stamp to foreign general public

**gigstack Connect:** Stamp other teams' receipts using the `team` parameter.




## OpenAPI

````yaml openapi.json POST /receipts/{id}/stamp
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:
  /receipts/{id}/stamp:
    post:
      tags:
        - Receipts
      summary: Stamp receipt
      description: >
        Convert a receipt into a CFDI invoice by stamping it with SAT.


        Only receipts with `status: pending` can be stamped. A receipt that
        already has

        entries in `invoices[]` is returned as-is with a `200` and no new CFDI;
        any other

        non-pending receipt (a cancelled one is stored as `completed`) is
        rejected with a

        `409`.


        **Stamp Options:**

        - `client`: Stamp to the associated client

        - `general_public_national`: Stamp to Mexican general public

        - `general_public_foreign`: Stamp to foreign general public


        **gigstack Connect:** Stamp other teams' receipts using the `team`
        parameter.
      operationId: createReceiptsByIdStamp
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
          example: receipt_1234567890
          description: Receipt ID
        - $ref: '#/components/parameters/TeamParameter'
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - stamp_to
              properties:
                idempotency_key:
                  type: string
                  nullable: true
                  example: stamp-receipt-2026-09-11-001
                  description: >-
                    Optional. A retry that reuses the key returns 409 with the
                    receipt id instead of attempting a second stamp.
                stamp_to:
                  type: string
                  enum:
                    - client
                    - general_public_national
                    - general_public_foreign
                  example: client
                  description: Who to stamp the receipt to
                fiscal_information:
                  type: object
                  nullable: true
                  properties:
                    legal_name:
                      example: Juan Pérez García
                      type: string
                      nullable: true
                    tax_id:
                      example: PEGJ800101ABC
                      type: string
                      nullable: true
                    tax_system:
                      example: '601'
                      type: string
                      nullable: true
                    zip:
                      type: string
                      nullable: true
                      example: '01000'
                  description: Custom fiscal information (overrides client data)
                date:
                  type: number
                  nullable: true
                  example: 1677651234000
                  description: Custom invoice date (timestamp in milliseconds)
            example:
              stamp_to: client
              date: 1767225600000
      responses:
        '200':
          description: >
            Receipt stamped successfully. **This handler predates the
            standardized

            envelope** — it returns the raw shape `{ "message": …, "data": … }`
            with no

            `success` or `timestamp` keys.
          content:
            application/json:
              schema:
                type: object
                required:
                  - message
                  - data
                properties:
                  message:
                    type: string
                    example: Receipt stamped successfully
                  data:
                    type: object
                    description: The stamped receipt.
              example:
                message: Receipt stamped successfully
                data:
                  id: receipt_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
                  currency: MXN
                  exchange_rate: 1
                  from: api
                  url: >-
                    https://invoicing.gigstack.pro/autofactura?id=receipt_1234567890
                  created_at: 1767225600000
                  invoices:
                    - B0C3E4F2-1A2B-4C5D-9E8F-0123456789AB
                  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
                  livemode: true
                  metadata:
                    order_id: ORD-12345
                  owner: user_1234567890
                  payments:
                    - payment_1234567890
                  periodicity: month
                  short_url: https://gigstack.xyz/Rc8vQ2
                  status: completed
                  team: team_1234567890
                  valid_until: 1769817600000
                  automatic_invoice_error: null
                  payment_form: '03'
                  total: 1160
                  total_refunded: 0
                  subtotal: 1000
                  taxes: 160
                  discount: 0
                  withholding_taxes: 0
                  idempotency_key: receipt-key-12345
        '400':
          description: >
            Bad Request, returned in the raw legacy shape. Cases:

            - body validation failure — `{ "error": "Invalid request body",
            "errors": [...] }`

            - `fiscal_information cannot be provided when stamp_to is
            general_public`

            - `fiscal_information is required when stamp_to is client and
            receipt has no client`
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/LegacyErrorResponse'
        '403':
          $ref: '#/components/responses/AuthForbidden'
        '404':
          description: >
            `Receipt data not found`, or `Client not found in database` when
            `stamp_to: client`

            resolves to a client document that no longer exists.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/LegacyErrorResponse'
        '409':
          description: >
            The receipt is not pending, so it cannot be stamped. Receipts that
            already

            produced a CFDI return `200` with their `invoices[]` instead.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/StandardErrorResponse'
        '500':
          description: >
            Internal error, raw shape. **PAC failures surface here as 500, not
            503** — when

            the stamping provider returns a non-OK response the handler emits

            `{ "error": <provider message>, "message": "Failed to process
            receipt: <status> <statusText>" }`.

            Also covers `Receipt reference not found` and the uncaught-exception
            body

            `{ "error": { "code": "stamp_receipt_handler_error", "message": …,
            "details": … }, "message": … }`.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/LegacyErrorResponse'
      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:
    LegacyErrorResponse:
      type: object
      description: >
        Raw error body returned by handlers that do not use the standardized
        helpers.

        Note the absence of `success` and `timestamp`.
      required:
        - message
      properties:
        message:
          type: string
          example: Invalid body
        error:
          oneOf:
            - type: string
            - type: object
          description: Present on most, but not all, legacy error paths.
        errors:
          type: array
          description: >-
            Field-level validation errors, when the failure came from body
            validation.
          items:
            type: object
            properties:
              path:
                type: string
                example: client_id
              code:
                type: string
                example: unexpected_key
              message:
                type: string
                example: Unexpected field
    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 `"<field path>: <message>"` 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
  responses:
    AuthForbidden:
      description: >
        Rejected by the authentication layer after the credential was
        recognised. The body is a raw

        object (`message`, sometimes `details`), **not** the standardized
        envelope. Causes:


        - The API key was revoked or disabled: `message: "API Key inválida."`,
        `details: "Invalid API Key"`.

        - The billing account's plan does not include API access. `message` is a
        Spanish sentence
          containing an HTML link to `https://app.gigstack.pro/memberships`. Branch on the status
          code; do not display or match the text.
        - gigstack Connect: the plan lacks the `multipleIssuerAccounts` feature
        (Spanish message
          starting `Tu plan no incluye múltiples cuentas emisoras.`), or an OAuth access token was
          sent with a `team` other than its own (`Team mismatch with OAuth token`).

        An endpoint may also answer `403` for its own reasons; those are
        documented on the

        operation when they exist.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/AuthMiddlewareError'
          examples:
            revoked_api_key:
              summary: API key revoked or disabled
              value:
                message: API Key inválida.
                details: Invalid API Key
            plan_without_api_access:
              summary: Plan does not include API access
              value:
                message: >-
                  La API se encuentra disponible para un plan más grande, por
                  favor actualiza tu plan <a
                  href='https://app.gigstack.pro/memberships'>aquí</a> o ponte
                  en contacto con soporte.
            connect_plan_without_multiple_issuers:
              summary: gigstack Connect — plan lacks multipleIssuerAccounts
              value:
                message: >-
                  Tu plan no incluye múltiples cuentas emisoras. Actualiza tu
                  plan en https://app.gigstack.pro/memberships o ponte en
                  contacto con soporte para operar sobre otros equipos.
            oauth_team_mismatch:
              summary: gigstack Connect — OAuth token used for another team
              value:
                message: Team mismatch with OAuth token
  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.