Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.tight.com/llms.txt

Use this file to discover all available pages before exploring further.

Now that you’ve finalized an invoice, you may find that your user needs the ability to take certain actions against those invoices.

​
1. Sending a payment reminder to the client

You can set an automatic reminder schedule when creating an invoice. However, you may want to allow your user to send a reminder to their client(s) on an ad-hoc basis. To do so, simply make a POST call to the /sendInvoiceReminders endpoint: 
curl \
  --request POST \
  --url https://sandbox.hurdlr.com/rest/v5/invoicing/sendReminders \
  --header 'Authorization: Bearer ${access_token}' \
  --header 'Content-Type: application/json' \
  --data '{
    "invoiceIds": [
        21850
    ]
  }'

​
2. Cancelling an invoice

If an invoice has been finalized and needs to be cancelled, you can do so by making the following POST call, including the relevant invoiceId: 
curl \
  --request POST \
  --url https://sandbox.hurdlr.com/rest/v5/invoicing/cancelInvoices \
  --header 'Authorization: Bearer ${access_token}' \
  --header 'Content-Type: application/json' \
  --data '{
    "invoiceIds": [
        21850
    ]
  }'

​
3. Updating an invoice’s recurrence schedule

You can update the recurrence schedule/frequency of a finalized recurring invoice by simply POSTing up the invoice object with an updated invoiceFrequency field. To stop it from recurring, you can simply change the invoiceFrequency to ONE_TIME: 
curl \
  --request POST \
  --url https://sandbox.hurdlr.com/rest/v5/invoicing/invoice \
  --header 'Authorization: Bearer ${access_token}' \
  --header 'Content-Type: application/json' \
  --data '{
    "id": 21850
    "invoiceFrequency": "ONE_TIME",
    "reminderSchedule": ["ON_DUE_DATE", "EVERY_SEVEN_DATES_AFTER_DUE_DATE"]
  }'
🚧 Updating closed invoices Once an invoice has been closed, cancelled, or refunded, it cannot be updated. Instead, we recommend creating a new invoice with duplicated information. This behavior is by design, so as to keep the Accounting functionality (i.e. General Ledger) clean, with a traceable audit trail.