> ## 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. # What we verified > Concrete test coverage and known behavior behind the small examples. Six Mexican walkthroughs—customer, invoice, payment, paid later, receipt, and credit note— were exercised on **2026-10-08** against `gigstackprodev` with a test key. The checks made **102 requests covering 40 distinct documented operations**: 87 exploratory requests plus 15 requests executed from the Bash blocks copied directly out of the six recipe pages. Those copied examples passed their response checks, and the preview decoded into a valid PDF. This includes successful flows, deliberate validation failures, and a confirmed unavailable gateway route. It is not a claim that all 155 documented operations have been exercised. Checks first used Discovery directly, then the staging gateway at `https://gigstack-staging-9z9nnaat.uc.gateway.dev/v2`. Direct handler checks alone do not prove gateway availability. Production behavior can differ until a release reaches `main`. ## Completed flows | Flow | Evidence | | - | - | | Customer | Create `201`, read/update `200`, search-or-create reuse `200` with the same ID | | Service | Create, read, update, and delete a synthetic service | | Lists and catalogs | Clients, services, payments, receipts, invoice types, drafts, retentions, webhooks, SAT lists, product/unit codes, CFDI error catalog | | Pagination | Followed a real customer cursor; the next page did not repeat the first record | | Invoice draft | Create/read/update/delete; a complete draft produced a PDF preview | | Test CFDI | Stamped a complete draft, received a UUID and `livemode: false`, retrieved invoice and files by UUID | | Payment | Recorded MXN 1,160; replay rejected with `400 resource_conflict` | | Receipt | Created/read/cancelled a test receipt; replay rejected with `400 resource_conflict` | | PPD and complements | Issued MXN 1,160; two MXN 580 payments produced complements; final balance `0` | | Overpayment | Rejected MXN 696 when the remaining balance was MXN 580 | | Credit note | Issued a related CFDI `E` for MXN 116; retrieved it by its new UUID | | Errors | Missing auth `401`, missing client `404`, invalid customer/draft/payment bodies `400` | | Gateway gap | `GET /documents` returned the gateway's `404` unavailable-route response | ## Additional record-only refund check On **2026-10-08**, an authorized staging run made **eight API requests**, including authentication and webhook prechecks, with a test MCP token and an explicit issuing-team selection. It created a fresh synthetic customer and succeeded MXN 1,160 manual payment, then submitted one MXN 116 refund with `external_processor_refund: false`. The refund returned HTTP `200`, `data.refund.total: 116`, `data.payment.amount: 116000` and `data.payment.total_refunded: 11600`. The refund record reported `succeeded`; the POST response’s payment `refund_status` was `requires_action`. Reading the payment again found the same refund ID, amount and reason, with `total_refunded: 11600`. That GET retained payment `status: "succeeded"` and did not expose `refund_status`. This verifies the record-only request, response units and persisted result. It did not request a Stripe refund or establish money movement. Before the write, published test Journeys and active webhook routing were empty, automatic refund handling was disabled, and the fresh payment had no fiscal or processor associations. No billing entitlement was changed. Synthetic test history remains in staging for reconciliation. ## Behaviors to account for * **Draft updates:** a notes-only `PUT` cleared `items`. Send the complete intended body and read it back before stamping. The published reference calls out this observed behavior rather than promising a partial update. * **Draft identity:** stamping returned `200` and `data.uuid`, without `data.id`. The former draft ID returned `404`; reading by the new UUID succeeded. * **Duplicate creation keys:** payments and receipts returned `400 resource_conflict`. Do not build duplicate handling around HTTP `409` alone. * **Receipt payment form:** the returned field was `null` despite input `03`. Verify the fiscal document instead of relying on that response field. * **Different response envelopes:** drafts use `{message, data}`; validation errors can use `{message, errors}`. Other endpoints commonly return `{success, data}` or `{success, error}`. ## What this run does not establish Production stamping, payment collection or refunds through a processor, external email or webhook delivery, account provisioning, changing fiscal credentials, SAT bulk downloads, retention stamping, and every advanced fiscal variant were **not verified** by this run. API reference coverage and a successful documentation build do not prove those workflows. The run used synthetic customers and test documents. It did not modify pre-existing business records. Test payment and CFDI history remains in staging for reconciliation. For coding agents, the [workflow examples](/examples/workflows.json) contain the request shapes, response fields to save, and completion checks used by the main recipes. ## Source review and offline contract checks The October 8 quality review also checked all resource guides and fiscal catalogs against their handlers and current supporting sources. Request-schema checks compare published fields, required keys, enums, and constraints against 22 shared/runtime schema mappings. Complete request examples are checked against the OpenAPI contract and mapped runtime validators. Response examples are checked against their published schema. These checks catch contradictions such as an omitted required quantity or a nullable response enum that rejects the API's own example; they do not execute account operations. The [Colombia example](/countries/colombia), [cancellation walkthrough](/recipes/cancellation), Stripe path in the [refund walkthrough](/recipes/refund), and issuer setup instructions remain **source-reviewed**. The record-only refund path was exercised separately as described above. Field mappings, completion checks and known limitations for unexecuted paths are documented separately from observed results. The canonical agent indexes are generated with a content revision. A successful local build establishes the expected content, while a live export check must establish that the published canonical URL actually serves it. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.