API Issuing
Issue invoices programmatically by integrating Brinta with your system or ERP — automated, real-time, and scalable.
API invoice creation is used when you need to issue invoices programmatically by integrating Brinta with your system or ERP.
This option is ideal when you:
- Want to automate invoice issuance
- Issue invoices in real time from your own system
- Work with large or continuous invoice volumes
- Need a scalable and fully integrated solution
With API invoice creation, you can:
- Send invoice data directly to Brinta via API
- Issue invoices without using the dashboard
- Handle multiple document types programmatically
- Receive real-time responses and validation results
This method follows the same validation rules as manual and bulk invoicing, including country-specific electronic invoicing requirements.
How it works
All invoice creation goes through a single endpoint:
POST https://api.brinta.com/invoices
The payload structure is the same across all countries and document types. What changes is which fields are required depending on the country and document type you're issuing.
The general flow is:
- Authenticate — include your API key in the request header.
- Build the payload — set
invoice_type,document_type, and the fields required for your country. - Send the request — Brinta validates, stamps, and returns the signed document.
- Handle the response — check the status and store the invoice ID and fiscal UUID returned.
Payload structure
Every request shares the same root structure:
| Field | Type | Required | Description |
|---|---|---|---|
supplier_company_id | string | Yes | UUID of the issuing company registered in Brinta. |
invoice_type | string | Yes | Type of document. Possible values: debit, payment, transport. |
document_type | string | Yes | Specific document format. Varies by country — see Invoice Document Types. |
invoice_date | string | Yes | Issuance date in YYYY-MM-DD format. |
invoice_serie | string | Varies | Invoice series or prefix. |
invoice_number | string | Varies | Invoice number or folio. |
currency | string | Yes | ISO 4217 currency code (e.g. MXN, PEN, COP). |
exchange_rate | number | Varies | Required when currency is not the country's local currency. |
e_invoice | boolean | Yes | Set to true to issue as an electronic invoice. |
reason | string | Varies | Usage or transport reason code. Country-specific SAT/SUNAT catalog. |
export_reason | string | Varies | Export or transfer reason. Required for MX transport documents. |
fiscal_status | string | Varies | Fiscal object code. Required for MX payment invoices (SAT c_ObjetoImp). |
additional_info | string | No | Free-text field appended to the document. Used for PE transport. |
payment_method | object or array | Varies | Payment method(s). Required for MX payment invoices. Send a single object, or an array of objects to split payment across multiple methods — see payment_method structure below. |
buyer | object | Yes | Buyer information including tax registrations and address. |
items | array | Varies | Line items. Required for standard invoices. |
senders | array | Varies | Origin locations. Required for MX and PE transport documents. |
beneficiaries | array | Varies | Destination locations. Required for MX and PE transport documents. |
transportation_companies | array | Varies | Drivers, owners, and carriers. Required for MX and PE transport documents. |
vehicle | object | Varies | Vehicle information. Required for all transport documents. |
amounts | array | Varies | Document-level payment amounts. Required for MX Payment Invoice Mode A. |
taxes | array | Varies | Document-level taxes. Required for MX Payment Invoice Mode A. |
relations | array | Varies | Related documents. Used for MX payment invoices and PE transport. |
payment_method structure
payment_method structurepayment_method accepts either a single object (as before) or an array of objects with the same shape, to split an invoice's payment across multiple methods (e.g. part bank transfer, part credit card).
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Varies | Type of payment method. Possible values: credit card, debit card, digital wallet, bank transfer, cash. |
name | string | No | Name of the payment method. |
bin | integer | No | BIN of the credit/debit card used for the transaction. |
last4 | integer | No | Last 4 digits of the credit/debit card used for the transaction. |
installment | integer | Varies | SAT NumParcialidad — installment number being paid (e.g. "this is installment #3"). Used for MX Payment Invoice (Complemento de Pago). |
bank_account | object | No | Bank account details (bank_name, account_number, account_number_alt, address.country). |
payment_model | object | No | type (credit or cash) and terms (e.g. net 30) describing how the transaction is settled. |
code | string | No | Code of the payment method. |
amount | number | No | Amount paid with this payment method. |
due_date | string | No | Due date for this payment method. |
installments | integer | No | Total number of installments for this payment method (e.g. a card paid in 2 installments). Not the same as installment above. |
bank_account_beneficiary | object | Varies (if object present) | Bank account of the payment beneficiary: account_id, account_number (required), bank_name, account_type, account_number_alt, swift_code, address.country, and beneficiary.company (required) — type, address (country, state, city, all required), name, legal_name, email, external_id, tax_registrations[], physical_address. |
bank_account_sender | object | Varies (if object present) | Same shape as bank_account_beneficiary, for the sender's bank account (sender.company instead of beneficiary.company). |
Example — single payment method (unchanged):
"payment_method": {
"type": "credit card",
"name": "Visa",
"bin": 400344,
"last4": 5563
}Example — multiple payment methods:
"payment_method": [
{
"name": "bank account",
"type": "bank transfer",
"code": "03",
"amount": 1000,
"due_date": "2026-08-20",
"installments": 1,
"bank_account_sender": {
"bank_name": "aaa",
"account_number": "123456"
}
},
{
"name": "VISA",
"type": "credit card",
"code": "03",
"amount": 2000,
"due_date": "2026-08-20",
"installments": 2
}
]Authentication
Include your API key in every request:
curl --request POST \
--url https://api.brinta.com/invoices \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--header 'Authorization: Bearer YOUR_API_KEY' \
--data '{...}'Document types by country
| Country | Document | invoice_type | document_type |
|---|---|---|---|
| ALL | Standard Invoice | debit | invoice |
| MX | Payment Complement | payment | payment invoice |
| MX | Bill of Lading — Road | transport | bill of lading road |
| MX | Bill of Lading — Air | transport | bill of lading air |
| MX | Bill of Lading — Sea | transport | bill of lading sea |
| MX | Bill of Lading — Rail | transport | bill of lading rail |
| PE | Transport (Guia de Remision) | transport | transport |
For a complete list see Invoice Document Types.
Response
A successful request returns 201 with the created invoice object, including:
id— Brinta invoice UUIDinvoice_key— Fiscal UUID (folio fiscal) stamped by the tax authoritystatus— Current invoice statusxml/pdf— Signed document links (where applicable)
For error codes and status descriptions see Invoice Status Codes and Invoice Errors.
Useful Links
Response
A successful request returns 201 with the created invoice object: id (Brinta UUID), invoice_key (fiscal UUID / folio fiscal), status, and xml/pdf signed document links where applicable.
Credit Notes (all countries)
Credit notes follow the same logic across all countries Brinta supports. A credit note is created by sending invoice_type: "credit" and referencing the original invoice being credited via original_invoice_id or original_invoice_external_id. See Credit Notes for the full field reference, including the multi-company origin_company_id case.
Country specifics
| Country | What exists today |
|---|---|
| Mexico | Standard invoice, payment invoice, 4 bill-of-lading (carta porte) transport modes, withholding invoice, ClaveProdServ, full CFDI 4.0 testing reference |
| Peru | Transport (guía de remisión), standard invoice, credit notes |
| Colombia | API issuing guide |
| Argentina | Standard invoices, credit/debit notes (FCE MiPyme), export invoice (Factura E) |
| Uruguay | Withholding codes, ticket / invoice / e-Resguardo payload examples |
| Brazil | NFSe (prefeitura-based), full Reforma Tributária sub-tree (API/bulk/manual changes, CST/cClassTrib codes, operation indicator codes, NBS codes) |
| Chile | Invoice and ticket payload examples |
| Panamá | Invoice and export invoice payload examples |
| Dominican Republic |
Updated about 3 hours ago
