Skip to main content
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

​
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 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, cancellation walkthrough, Stripe path in the refund walkthrough, 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.