Skip to main content

Event types

General event types

Creditworthiness

This event type is only available when creditworthiness monitoring is enabled for an administration. In addition a creditworthiness profile is added to the debtor containing the most recent creditworthiness information. When monitoring an autogenerated credit limit is enabled for an administration, the autogenerated_credit_limit_amount field is added to the debtor data.

Special events

case_step_performed

The case_step_performed event can have different “name” values:
  • summons
  • summons_reminder
  • second_summons
  • second_summons_reminder
  • notice_of_default
  • prejudiciary

invoice_payment_created

Every time the amount that the debtor needs to pay for an invoice changes this event is triggered. The event contains details about the amount, currency, date, etc.

amount

The value of the payment in currency. This is the amount as the debtor will see it.

book_amount

The value of the payment in book_currency. Use this amount when synchronizing with accounting software. A negative value indicates a debit transaction, a positive value indicates a credit transaction.

book_currency

This is the currency that belongs to the book_amount value. It is the currency in which the administration does its bookkeeping.

cost_type

Payt makes a distinction between payments for the original amount of the invoice and for payments of additional costs added by Payt. When (part of) the total_amount of the invoice is paid the cost_type will be “principal”. Payments with this type are created when Payt imports data from the accounting software. The sum of all “principal” payments is equal to the difference between the total_amount and open_amount of the invoice. When costs are added to an invoice then payments will be added that have “costs” as a suffix. Payt currently supports 3 types of costs: “administration_costs”, “interest_costs” and “debt_collection_costs”.

currency

This is the currency that belongs to the amount value. It is the currency of the invoice.

invoice_step_performed

The invoice_step_performed event can have different “name” values:
  • reminder_1
  • reminder_2
  • reminder_3
  • reminder_4
  • storno_reminder
  • final_reminder
  • invoice_pause
  • pre_reminder
  • start_debt_collection
  • credit_note_send
  • invoice_send
  • zero_amount_invoice_send
  • direct_debit_invoice_send
  • debtor_call
  • forward_to_external_party

Examples

invoice_created

invoice_paid

invoice_paused

See invoice_created

invoice_blocked

See invoice_created

invoice_resumed

See invoice_created

invoice_payment_created

invoice_closed

invoice_reopened

invoice_call_reminder_performed

payment_plan_created

The requests for payment_plan_updated, payment_plan_finished and payment_plan_deactivated are similar, the only difference is the event_name.

invoice

debt collection case (resource_type: credit_case)

payment_plan_term_expired

invoice_new_comment

case_new_comment

debtor_new_comment

message_created

Sent for every message created in Payt: messages sent by the debtor, messages sent by a user of the creditor, and messages Payt sends on the creditor’s behalf (such as automatic replies). sender_type is debtor or creditor. The administration object is always present; debtor, invoice, credit_case and user are null when the message is not linked to such a record. subject is only filled for messages that arrived by email; it is null for messages written in Payt or in the debtor portal. The same holds for from_email_address: a message written by a user of the creditor has no sender address of its own. to_email_addresses lists the recipients the message was sent to, and is empty when the message was not emailed. Automatic system notifications (such as the confirmation of a changed email address) do not trigger this event. If you use an OAuth application, it needs the messages:read scope to receive this event. Webhooks you set up directly on an administration always receive it.

note_created

Sent when an internal note is created on a debtor, invoice or debt collection case, either by a user or from an incoming email reply. The administration and debtor objects are always present; invoice and credit_case are null when the note is not linked to such a record. from_email_address is filled when the note was created from an incoming email reply, in which case user is null. completed_at is always null in this event: a note can only be completed after it has been created. If you use an OAuth application, it needs the notes:read scope to receive this event. Webhooks you set up directly on an administration always receive it.

psp_transaction_successful

invoice

debt collection case (resource_type: credit_case)

payment plan

psp_transaction_charged_back

invoice

psp_transaction_refunded

invoice

todo_list_item_created

todo_list_item_updated

See todo_list_item_created

todo_list_item_deleted

See todo_list_item_created

invoice_step_performed

invoice_to_debt_collection

bundled_reminder_sent

bundled_reminder_invoice_performed

case_created

case_step_performed

case_to_bailiff

case_paid

case_invoice_amount_paid

case_reopened

credit_limit_exceeded

label_added

invoice

debtor

debt collection case (resource_type: credit_case)

label_removed

invoice

debtor

debt collection case (resource_type: credit_case)

debtor_email_address_provided

debtor_email_address_removed

creditworthiness_changed

psp_mandate_created

psp_mandate_revoked

invoice_sms_failed

invoice_ubl_failed

incoming_ubl_received

invoice_letter_returned

email_bounced

The administration and debtor objects are always present. Of the invoice, credit_case, bundled_reminder, and message objects exactly 1 will be present.

invoice_email_bounced

bundled_reminder_email_bounced

bundled_reminder_letter_returned

case_email_bounced

case_letter_returned

Last modified on September 28, 2026