Skip to main content
You can create the same basic customer record for a Mexican or Colombian issuing business:
Send this body to POST /clients. Follow Create a customer once for the complete request and duplicate lookup. Add fiscal details from the country guide before using the customer on an invoice.

Mexico · CFDI

RFC, fiscal regime, Uso CFDI, SAT product codes, and payment complements.

Colombia · DIAN

Identification type, NIT, fiscal responsibilities, and municipality codes.

Choose the issuing country first

The issuing team’s invoicing configuration selects the country and provider. client.address.country describes the customer; it does not switch the issuer to another country’s invoicing system. A Mexican issuer selling to a Colombian customer still uses the Mexican invoicing flow, with the appropriate foreign-recipient details. Start with issuer setup to confirm the country, credentials, numbering and environment. The public team response does not expose provider selection. For multiple issuing businesses, select the intended team through the documented gigstack Connect flow. Confirm its invoicing setup before issuing. Currency and test mode are separate choices; neither selects the issuing country.

Shared customer fields

These fields belong to the customer API in both country flows. “Optional” below means optional when creating a contact, not necessarily sufficient for issuing an invoice. tax_system and use describe Mexican fiscal data. Colombia adds document_type, organization_type, tribute_code, fiscal_responsibilities, dv, and municipality_code. See the country pages for their meaning and behavior.

Shared invoice fields

Both flows use the same invoice routes. The table describes the common structure; the income invoice reference defines exact types and required fields for immediate issuance. Draft creation has different requirements and can accept incomplete information.

Shared names can have different meanings

POST /invoices/income currently requires use, payment_form, and payment_method even for a Colombian issuing team. The request validator accepts the published SAT-style payment codes and PUE / PPD; the Colombian adapter maps those values to its provider. Read the Colombia compatibility fields before adapting a Mexican example. Do not assume a field accepted by the shared schema is used by every country’s provider. The API reference lists accepted input; the country guides explain its fiscal meaning.