beel_create_recurring_invoice_derivation
Create a recurring invoice template by copying lines, recipient, series, and payment data from an existing invoice. Define only the recurrence; source invoice is not modified.
Instructions
Creates a recurring invoice template of this company taking its lines, recipient, series
and payment data from the invoice named in from_invoice_id, so only the recurrence has to
be described. The source invoice is not modified.
Omitting verifactu_enabled inherits the value of the source invoice; send it explicitly
to override that inheritance.
Endpoint: POST /v1/companies/{company_id}/recurring-invoices/derivations
⚠️ Fiscal guardrails — read before calling:
How BeeL derives the AEAT invoice type, and the rules each type imposes. (resource: beel://guardrails/invoice-types)
What regime_key means, where it lives, and which combinations are rejected. (resource: beel://guardrails/regime-keys)
For the exhaustive rules and worked examples, call beel_docs_search.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| company_id | Yes | NIF (company) the operation acts on. It is the only source of context: the account that owns it is derived from it, and the `BeeL-Active-Company` header plays no part. A NIF you do not reach answers `403`, and so does a NIF that does not exist, so the existence of a NIF in another account is never disclosed. | |
| idempotency_key | No | Optional idempotency key for this operation. Omit it and one is derived from the request itself, which makes a blind retry safe but also collapses a SECOND, deliberately identical operation into the first for 24 hours. Set it — to an order id, or anything unique per intended operation — whenever you mean to create something that may look identical to what you just created. |