Skip to main content
POST
Create a recurring invoice
Authentication: API key OAuth 2.0
Scope: client_invoice.write
Price plans: this endpoint requires a price plan or add-on that includes recurring invoices, such as the Invoice Automation add-on. Without it, requests return 403. It is not available for organizations in Belgium or Portugal. Requests also return 403 with code permission_denied while the organization’s KYB is not yet accepted.
Automatic numbering required. The organization must have numbering_mode set to automatic (see GET /v2/settings) before a recurring invoice can be created. Otherwise this call returns a 412 with code invalid_numbering_mode. Call PUT /v2/settings with {"numbering_mode": "automatic"} first.
A create can generate a real invoice immediately. If start_date is today (UTC), the first invoice is created in the same request, its id is returned as invoice_id, and the recurring invoice’s status is active. When invoice_status is unpaid, that invoice is also emailed to the client straight away. If start_date is in the future, no invoice exists yet: invoice_id is absent and status is scheduled.
start_date cannot be in the past (UTC). email_template is required when invoice_status is unpaid (the default), because the generated invoice is sent by email using it. It can be omitted when invoice_status is draft. Organizations with an Italian legal country must send payment_reporting. Without it the create is rejected with a 422.
Not supported yet: a recurring invoice cannot carry a welfare fund, a withholding tax or a stamp duty. welfare_fund, withholding_tax and stamp_duty_amount are accepted on POST /v2/client_invoices. Here they are ignored if sent, and no recurring invoice endpoint returns them. Use the Qonto app for a recurring invoice that needs one of them.
Not supported at creation: discount (a discount covering the whole invoice), purchase_order, terms_and_conditions, header, footer, end_date and payment_link are ignored if sent here. They can be set afterwards with PUT /v2/recurring_invoices/{id}. A per-item discount is supported at creation.

Authorizations

Authorization
string
header
required

Bearer authorization header: Bearer <token>, where <token> is the access token received from the authorization server at the end of the OAuth 2.0 flow.

Headers

X-Qonto-Staging-Token
string

Required only for Sandbox API requests; to get one, please sign up to the Developer Portal.

Body

application/json
client_id
string<uuid>
required

The client this recurring invoice bills.

Example:

"5c1f4e3a-9b7d-4a1e-8f2c-3d6b8a0e7f11"

start_date
string<date>
required

The date of the first occurrence. Cannot be in the past (UTC).

Example:

"2030-01-01"

frequency
object
required

Together, value and recurrence define the schedule. For example, {"value": 2, "recurrence": "monthly"} bills every two months.

payment_terms_days
integer
required

Days between an occurrence's invoice date and its due date.

Required range: 0 <= x <= 365
Example:

30

bank_account
object
required

The bank account generated invoices are paid to, identified by IBAN.

items
object[]
required

The line items billed on every occurrence.

Minimum array length: 1
invoice_status
enum<string>
default:unpaid

The status each generated invoice is created as.

Available options:
draft,
unpaid
currency
string
default:EUR

Currency for the recurring invoice and its items, as an ISO 4217 trigram. Defaults to EUR. Every item without its own unit_price.currency uses this value.

Example:

"EUR"

email_template
object

How each generated invoice is emailed to the client. Required when invoice_status is unpaid (or omitted, since that's the default); optional when invoice_status is draft.

payment_reporting
object

Italian payment reporting details, required for organizations with an Italian legal country. When sent, both method and conditions are required. Non-Italian organizations should not send this property.

Response

Returns the created recurring invoice.

recurring_invoice
object
required