Skip to main content
PUT

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.

Path Parameters

id
string
required

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

Body for the PUT /payments/{id} endpoint. At least one of items, automation_type or client must be present.

  • items: Update the description of one or more items in the payment, matched by item id. Only description can be modified — taxes, discounts, quantities and unit prices are immutable from this endpoint and any other field is rejected.
  • automation_type: Add automations to a payment that does not have any. If the payment already has automations, the request is rejected with 400. When non-empty automations are added and the payment status is succeeded, the status is flipped to succeeded_ after the update so the automation trigger can re-fire.
  • client: Update fields of the client embedded in the payment (name, email, fiscal info, address, etc.). The client id cannot be changed. Any provided field is also written to the matching /clients/{id} document via a partial merge, so the client master record stays in sync with the payment. Fiscal/SAT validation is not re-run from this endpoint — use PUT /clients/{id} if you need that.
items
object[] | null

List of items to update. Only the description of each item can be modified.

Minimum array length: 1
automation_type
enum<string> | null

Automation to attach to the payment. Only allowed if the payment currently has no automations.

Available options:
pue_invoice,
ppd_invoice_and_complement,
none,
null
Example:

"pue_invoice"

invoice_config
object | null
client
object | null

Partial update for the client embedded in the payment. Only the listed fields can be modified — the client id cannot be changed. Each provided field is propagated to the /clients/{id} master document via a partial merge.

Response

Payment updated successfully

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

Human-readable summary. Present only when the handler supplies one.

Example:

"Operation completed successfully"