Skip to main content
POST

Authorizations

Authorization
string
header
required

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

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.

Query Parameters

team
string

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

Body

application/json

Unknown top-level keys are rejected (400 validation_failed / unexpected_key). team, livemode and owner are reserved and injected by the auth middleware.

client
object
required
automation_type
enum<string>
required

Payment automation type:

  • pue_invoice: Create PUE (Pago en Una sola Exhibición) invoice immediately when payment succeeds
  • ppd_invoice_and_complement: Create PPD (Pago en Parcialidades o Diferido) invoice immediately, then payment complement when payment succeeds
  • none: No automation, register payment only
Available options:
pue_invoice,
ppd_invoice_and_complement,
none
Example:

"pue_invoice"

currency
string
required

Currency code (ISO 4217)

Example:

"MXN"

items
object[]
required
Minimum array length: 1
payment_form
enum<string>
required

Mexican SAT payment form code:

  • 01: Cash
  • 02: Check
  • 03: Electronic transfer
  • 04: Credit card
  • 05: Electronic money
  • 06: Digital money
  • 08: Gift voucher
  • 12: Credit for unregistered bills
  • 13: Payment by subrogation
  • 14: Payment by consignment
  • 15: Condonation
  • 17: Compensation
  • 23: Novation
  • 24: Confusion
  • 25: Remission of debt
  • 26: Prescription or expiration
  • 27: To creditor's satisfaction
  • 28: Credit card
  • 29: Debit card
  • 30: Service card
  • 31: Applicable only to the complementary concept of donations
  • 99: To be defined
Available options:
01,
02,
03,
04,
05,
06,
08,
12,
13,
14,
15,
17,
23,
24,
25,
26,
27,
28,
29,
30,
31,
99
Example:

"03"

exchange_rate
number | null

Exchange rate for currency conversion. If not provided, the rate from the payment date (or current date if no date specified) will be fetched automatically from our rates collection.

Example:

1

idempotency_key
string | null

Stable key for one business event. A duplicate returns HTTP 400 with error.code resource_conflict, not the existing payment as a successful response. Reconcile the existing record and retain this key; do not create a new key for a retry.

Example:

"payment-register-12345"

metadata
object | null

Additional metadata to store with the payment

invoice_config
object | null

Optional invoice configuration. Every field is optional. Controls the folio/serie the generated invoice will use, its issue date, the global (EOM) period it belongs to, and how long the self-invoicing window stays open.

date
number | null

Unix epoch timestamp in milliseconds (13 digits) for when the payment was received. Must be in the past. Defaults to now.

Example:

1767225600000

send_email
boolean | null

Accepted for compatibility, but on this endpoint it has no effect — only ignore_emails is persisted onto the payment. Use ignore_emails to suppress mail.

Example:

true

ignore_emails
boolean | null

Suppress email and WhatsApp notifications for this payment and any documents it automates (invoices, receipts). Defaults to false.

Example:

false

ppd_invoice_id
string | null

UUID of an existing PPD invoice to link this payment to. When provided, a payment complement (complemento de pago) will be automatically generated and linked to the PPD invoice. The referenced invoice must have payment_method='PPD', status='valid' and invoice_type='I' — a payment complement only ever settles an income CFDI, never an egress one.

Example:

"invoice_ppd_1234567890"

transfer_data
object | null

Configuration for splitting payments between master and connect teams in a marketplace. Only available for master teams with marketplace-enabled billing accounts.

All-or-nothing: the object itself is optional, but when it is present master, connect, master_to and connect_to are all required. Sending transfer_data with any of them missing fails validation with 400 validation_failed. connect_custom_config stays optional.

Response

Payment registered successfully. Both the standard path and the transfer_data split path return 201 with the standardized success envelope.

Standardized success envelope emitted by sendSuccessResponse.

success
enum<boolean>
required
Available options:
true
Example:

true

data
object
required

The operation payload.

timestamp
integer<int64>
required

Server time in epoch milliseconds (Luxon.now().toMillis()).

Example:

1767225600000

message
string

Payment registered successfully on the standard path, Split payments registered successfully on the split path.

Example:

"Payment registered successfully"