Payment updates and deletes

New: Update and delete a payment by its own id

You can now edit or remove a recorded payment directly — these are the first payment endpoints that aren’t scoped under an invoice or bill.

MethodPathDescription
PATCH/payments/{payment_id}Update a payment (PUT also accepted, as an alias)
DELETE/payments/{payment_id}Delete a payment

Update a payment

PATCH /payments/{payment_id}
1{
2 "amount": 150,
3 "notes": "Corrected amount after customer call"
4}

All fields are optional, but at least one is required: amount, paymentMethod, paymentDate, notes, paymentReference — the same set accepted on create. status is not exposed here, matching the Coperniq UI’s edit form.

Notes

  • If the payment is external (processed by Stripe), PATCH only accepts notes — any other field returns 400. DELETE is rejected outright for external payments; use a refund instead.
  • Changing amount can return 400 if the new total would exceed the parent invoice’s or bill’s outstanding balance.
  • Updating or deleting a payment recalculates the parent invoice’s/bill’s amountPaid and status automatically (e.g. back to PARTIALLY_PAID or SENT after a delete).
  • Responses use the same Payment/BillPayment shape as the existing list/get endpoints — billNumber for a bill payment, invoiceNumber for an invoice payment.

Choose the company for a new API key

POST /api-keys (and its legacy alias GET /token) now accepts an optional company_id query parameter, for accounts where the same login belongs to more than one company. Your company ID can be found in the URL after logging in to the Coperniq UI: https://app.coperniq.io/{company_id}/inbox.

POST /api-keys?company_id=123
  • If you belong to more than one company and pass company_id, the new key is created against that company. You must belong to it, or the request is rejected.
  • If company_id is omitted, the company is now chosen deterministically: your first non-collaborator company, falling back to your first company. Previously this could disagree with which company the key actually got created against, occasionally surfacing as a Failed to fetch token error even though a key had been created — just against an unexpected company.
  • Single-company accounts are unaffected either way.