description of items, attaching automation_type to a payment that has no automations, and patching the embedded client (with the change propagated to the /clients/{id} master record). The body must include at least one of items, automation_type or client.team parameter.items, the item is matched by id inside the payment and its description is replaced. Any other field on the item (taxes, discounts, quantity, unit_price, etc.) is rejected by validation. Item totals, taxes and itemsAmounts are not recalculated.automation_type is only accepted when the payment has no existing automations. If the payment already has automations, the request returns 400. The same enum values used by POST /payments/register apply (pue_invoice, ppd_invoice_and_complement, none).client object accepts a partial patch (name, company, phone, email, bcc, metadata, legal_name, tax_id, use, tax_system, address). The client id cannot be modified. Each provided field is written both to the client embedded in the payment and to the /clients/{id} master document via a partial merge. Fiscal/SAT validation is not re-run from this endpoint — call PUT /clients/{id} if full re-validation is needed.automation_type is pue_invoice or ppd_invoice_and_complement) and the payment is already succeeded, the endpoint performs a second write that sets status to succeeded_ so that the downstream automation trigger (which fires on transitions into succeeded) can re-fire on a subsequent flip back to succeeded.succeeded and cancelled) so descriptions can be corrected after the fact. Note that this endpoint does not re-issue or modify any CFDI already linked to the payment.curl --location --request PUT 'https://api.gigstack.io/v2/payments/?team' \
--header 'Authorization: <api-key>' \
--header 'Content-Type: application/json' \
--data-raw '{
"items": [
{
"id": "service_1234567890",
"description": "Servicio de consultoría profesional - corregido"
}
]
}'{
"message": "Operation completed successfully",
"data": {}
}