BeeL

Returns, for each related entity id given, how many emails the history holds for it, the status of the most recent one and when it was sent. Lets you show the state of an entity's email without loading its full history. - **`last_status`:** carries whatever the latest attempt ended in, `REJECTED` and `QUEUED` included, so a `count` above zero does not mean an email reached anyone. - **Ids with no associated emails:** omitted from the response rather than returned with `count` 0. **Closed catalogue.** This collection is fixed and bounded by the request itself — at most one indicator per id in `related_entity_ids`: it carries no `pagination`, it takes no `page`/`limit`, and every response holds the whole set. Endpoint: GET /v1/accounts/{account_id}/email-indicators

Returns the VAT and IRPF summary of the invoices issued under this company over the requested period, together with the annual IRPF projection and its progressive bracket breakdown. `start_date` and `end_date` go together: send both, or neither. Omitting both defaults to the current month; sending only one answers `400`, because a period you did not ask for is worse than an error. The range may not exceed 365 days, and every fault names itself in `details.reason`. Endpoint: GET /v1/companies/{company_id}/fiscal-summary

Returns one invitation of the account, with the same shape the list returns. An invitation stays readable for its whole life: `ACCEPTED`, `REVOKED` and `EXPIRED` ones are returned with their `status`, because the record is the trail of who was granted access to the account's fiscal data and revoking it does not erase it. Endpoint: GET /v1/accounts/{account_id}/invitations/{invitation_id}

Retrieves the full details of an invoice of this company. Endpoint: GET /v1/companies/{company_id}/invoices/{invoice_id} ⚠️ Fiscal guardrails — read before calling: - When an invoice can still be changed, and what to do once it cannot. (resource: beel://guardrails/invoice-state-machine) For the exhaustive rules and worked examples, call beel_docs_search.

Returns how the invoices of a company are rendered and delivered: PDF template, accent colour, invoice language, email language and current logo. Customization is a per-NIF property, so each company of the account carries its own. The catalogue of available templates and suggested colours is served by `GET /v1/invoice-customization-options`. Endpoint: GET /v1/companies/{company_id}/invoice-customization

Returns a temporary pre-signed URL to download the invoice PDF. - **URL:** expires in five minutes and only allows `GET`. - **`202`:** the PDF is still being generated and no body is returned; poll this endpoint until it answers `200`. - **Drafts:** a draft has no fiscal PDF and answers `400 INVOICE_NOT_ISSUED_NO_PDF`. Issue it, or render it with `GET …/{invoice_id}/pdf/preview`. Endpoint: GET /v1/companies/{company_id}/invoices/{invoice_id}/pdf

Returns a temporary pre-signed URL to a preview image (WebP) of the invoice, suitable for inline rendering. The image is generated and cached on first request, so a later call returns the cached image. The URL expires in five minutes and only allows `GET`. Endpoint: GET /v1/companies/{company_id}/invoices/{invoice_id}/preview

Returns the date and generation mode currently scheduled for this invoice. An invoice with no scheduling answers `404`, since the sub-resource does not exist yet. To move only the date, read the current `generation_mode` here and send it back on the `PUT`. Endpoint: GET /v1/companies/{company_id}/invoices/{invoice_id}/schedule ⚠️ Fiscal guardrails — read before calling: - When an invoice can still be changed, and what to do once it cannot. (resource: beel://guardrails/invoice-state-machine) - Choosing wrong here misreports to AEAT. The 30-second decision. (resource: beel://guardrails/cancel-vs-rectify) For the exhaustive rules and worked examples, call beel_docs_search.

Returns whether a company can issue its STANDARD invoice right now in the environment of the request, and the `blockers` that stop it otherwise. Readiness is a per-NIF property, evaluated independently for each company of the account. - **`ready`:** `true` only when `blockers` is empty. - **Activation:** issuing any fiscal document requires the company to be activated in the environment of that document, whether or not it goes to VeriFactu. - **VeriFactu chain:** the AEAT census and signed representation are additionally demanded only when the company applies VeriFactu by default, the same derivation invoice creation uses when `verifactu_enabled` is omitted. A company with VeriFactu off is ready with a NIF, a default series and an activation. Issuing an invoice with an explicit `verifactu_enabled: true` still enforces the full chain at emission time regardless of this answer, and the separate `verifactu` block reports that chain independently of the setting. - **Not evaluated:** the account's quota or subscription, and the payload of any particular invoice. Endpoint: GET /v1/companies/{company_id}/issuing-readiness ⚠️ Fiscal guardrails — read before calling: - Which company an operation acts on, and how that is selected. (resource: beel://guardrails/multi-nif) For the exhaustive rules and worked examples, call beel_docs_search.

Returns one member of the account, with the same shape the list returns. Endpoint: GET /v1/accounts/{account_id}/members/{member_id}

Returns the identity of the authenticated principal: the account the credential belongs to, the person's email, name, logo and interface language, and a description of the credential itself. Unlike every other operation, it requires no scope — any valid credential resolves, so a `200` confirms the credential works and tells you which account it belongs to, and a `401` that it does not. - **`account_id`:** identifies who the credential belongs to, not what it is currently pointed at; selecting a different company with `BeeL-Active-Company` does not change it. - **`name`:** resolves as `trade_name ?? legal_name` of the active fiscal profile, and is `null` until onboarding creates one. - **`credential`:** describes the credential the call was authenticated with — its type, the environment it operates on and the permissions it holds — so a client can adapt what it offers instead of discovering the limits through a `403`. - **Caching:** responses are never cached (`Cache-Control: no-store`). Endpoint: GET /v1/me/identity

Retrieves a single payment event of the NIF's connection, including the outcome of its automatic invoicing and, when it failed, the stable failure code you can act on. - **Not found:** an event that does not belong to this NIF's connection returns `404`, the same answer an event that does not exist gets, so an event of another NIF is never disclosed. Endpoint: GET /v1/companies/{company_id}/payment-connections/{provider}/events/{event_id}

Retrieves the details of a product of this company. Endpoint: GET /v1/companies/{company_id}/products/{product_id}

Retrieves the full details of a recurring invoice template of this company, including its schedule, template lines and next generation date. Endpoint: GET /v1/companies/{company_id}/recurring-invoices/{recurring_invoice_id} ⚠️ 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.

Returns the invoices previously generated from this recurring template, including their status and generation dates, newest first. **Paginated** with the usual `page`/`limit`, and the usual defaults: without them you get the 20 most recent generations, not the whole history — which grows with every cycle the template runs. Read `data.pagination` to walk the rest. The deprecated flat alias `GET /v1/recurring-invoices/{recurring_invoice_id}/history` does **not** paginate: it is frozen as it shipped until its `Sunset` date, and returns the whole history with no `pagination`. Only this route pages. Endpoint: GET /v1/companies/{company_id}/recurring-invoices/{recurring_invoice_id}/history ⚠️ 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.

Returns the invoice that would be produced by the next generation of this recurring template, computed from the current issuer, recipient and series data. Nothing is persisted and no numbering is consumed. Endpoint: GET /v1/companies/{company_id}/recurring-invoices/{recurring_invoice_id}/next-occurrence ⚠️ 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.

Returns the state of the AEAT fiscal representation of a company: whether the document has been generated, signed and submitted, and whether AEAT accepted it or it was cancelled. - **`status`:** `NOT_STARTED`, `PDF_GENERATED`, `SUBMITTED`, `ACTIVE`, `ERROR` or `CANCELLED`. - **Never started:** not an error. The endpoint answers `200` with `NOT_STARTED`, so polling it is always safe. Endpoint: GET /v1/companies/{company_id}/representation

Returns the full detail (bodies and headers) of a request made by you, with any of your API keys in this environment — including one made with a key other than the one you are authenticating with, because the axis is the person, not the individual credential. - **`{account_id}`:** authorizes the call; it does not widen what you can see. - **`404`:** the request does not exist, was made by another user (including another user of this same account), or belongs to the other environment. - **The widest read `logs:read` opens:** it returns the bodies and headers that any key of yours exchanged in this environment, so a key holding only `logs:read` reads the traffic of your privileged keys too. It never crosses to another user or to another account. Grant it accordingly. Endpoint: GET /v1/accounts/{account_id}/request-logs/{request_id}

Returns one invoice series of a company, with its code, format, counter state, document type and whether it is the default of that type. Endpoint: GET /v1/companies/{company_id}/series/{series_id} ⚠️ Fiscal guardrails — read before calling: - How invoice numbers are formed, and why numbering can never be rewritten. (resource: beel://guardrails/series-and-numbering) For the exhaustive rules and worked examples, call beel_docs_search.

Read-only setup status across your account: for each company it reports whether it can issue Live, exactly what is missing (issuing-readiness blockers, default series, VeriFactu, payment connection) and the single recommended next action. Use this to drive onboarding instead of guessing. Aggregates several endpoints; a section that could not be read carries an `error` and never a default, so an unknown is never reported as ready.

Returns the tax configuration of a company: its default main tax (`IVA`, `IGIC`, `IPSI` or `OTHER`) with the default percentage and regime key, the default exemption reason, its IRPF and equivalence surcharge settings, and the default payment method and payment term. The catalogue of tax types this configuration draws from is not company data and lives outside this resource. Endpoint: GET /v1/companies/{company_id}/tax-configuration

Returns how many accounts you have provisioned and the billable count that follows from them — the figure behind your offline B2B invoice. - **Billable unit:** the provisioned account, not the real NIF. Every account you provision counts as one, empty and unclaimed ones included. - **`account_id`:** your own account. Usage is a property of the provisioner, not of each provisioned account, so any other id returns `404`. - **Entitlement:** requires `manage_accounts`. Endpoint: GET /v1/accounts/{account_id}/usage

Retrieves the VeriFactu configuration of this company. The configuration belongs to the NIF, so the NIF in the path is what decides which one is returned. Endpoint: GET /v1/companies/{company_id}/verifactu-configuration ⚠️ Fiscal guardrails — read before calling: - Why an issued invoice may never reach AEAT, and how to tell before issuing. (resource: beel://guardrails/verifactu-gates) For the exhaustive rules and worked examples, call beel_docs_search.

Returns a single webhook subscription. The signing secret is never included. Endpoint: GET /v1/accounts/{account_id}/webhooks/{webhook_id}

Opens an authorization session so the holder of a company your account **manages** can connect a payment provider (`stripe`), and returns the `authorization_url` where they authorize it. - **`return_url`:** once the holder authorizes, BeeL's callback finalizes the connection and redirects back to the `return_url` of your portal, if you supplied one, with the parameters described under `return_url`. - **When the connection appears:** it is created only when the holder authorizes, so it does not appear in `GET /v1/companies/{company_id}/payment-connections` until then. It is sealed under the NIF in the path, so auto-invoicing issues under that NIF. - **The NIF must be activated in the mode of your API key** (`beel_sk_test_*` → Test, `beel_sk_live_*` → Live); otherwise the request answers `400` `COMPANY_NOT_ACTIVATED_IN_ENVIRONMENT` and no `authorization_url` is issued, because without activation there is no invoice series or tax configuration to invoice with. Test and Live activations are independent — a NIF activated in one mode still needs activating in the other. - **One provider account, one NIF:** a provider account (`acct_...`) can be connected to a single NIF across the whole platform. Authorizing the same provider account from a second NIF does not move it: the callback fails with `OAUTH_ACCOUNT_CONNECTED_TO_OTHER_COMPANY`, and the existing connection keeps invoicing under the NIF it was sealed with. To move it, first `DELETE /v1/companies/{company_id}/payment-connections/{provider}` on the NIF that holds it, then open a new authorization on the NIF you want it under. Endpoint: POST /v1/companies/{company_id}/payment-connections/authorizations

Finalizes a draft invoice of this company: assigns its definitive number from the configured series and makes it immutable. - **Irreversible:** an issued invoice is corrected with a corrective invoice (`POST …/{invoice_id}/corrective`) or voided (`POST …/{invoice_id}/void`), never edited. - **Asynchronous:** PDF generation and submission to the AEAT happen after the response, so a `200` means the invoice was accepted for submission, not that the AEAT has registered it. Use `wait_for_pdf` to wait for the PDF. Endpoint: POST /v1/companies/{company_id}/invoices/{invoice_id}/issue ⚠️ Fiscal guardrails — read before calling: - When an invoice can still be changed, and what to do once it cannot. (resource: beel://guardrails/invoice-state-machine) - Why an issued invoice may never reach AEAT, and how to tell before issuing. (resource: beel://guardrails/verifactu-gates) For the exhaustive rules and worked examples, call beel_docs_search.

Returns the accounts you provisioned, newest first. Each carries its lifecycle `status` (`PROVISIONED` → `CLAIMED` → `ACTIVE`), the `access_level` you hold over it and the state of its claim link. - **`status`:** narrows the list to one lifecycle stage. - **`external_ref`:** looks an account up by the reference you assigned when provisioning it; returns the 0..1 matching accounts. **Cursor pagination.** This collection pages by `cursor`/`next_cursor` instead of by `page`, so it carries no `pagination` block. That is a documented variant of pagination, not a different envelope: the collection still travels under a named key inside `data`. Keep asking with the `next_cursor` of the previous response until it comes back `null`. Endpoint: GET /v1/accounts

Returns the companies (NIFs) belonging to the account in the path, ordered with the primary company first. An account with no companies yet returns an empty list rather than an error. - **`search`:** filters case-insensitively on NIF, legal name and trade name. - **`include=readiness`:** adds each company's issuing-readiness block. - **`pagination`:** present only when the request is paginated — that is, when any of `page`, `limit` or `search` is sent. It is omitted for the full list. - **Series:** not part of this response. Read them from `GET /v1/companies/{company_id}/series`. Endpoint: GET /v1/accounts/{account_id}/companies ⚠️ Fiscal guardrails — read before calling: - Which company an operation acts on, and how that is selected. (resource: beel://guardrails/multi-nif) For the exhaustive rules and worked examples, call beel_docs_search.

Returns a paginated list of the customers of this company, with optional filters. Only the customers of the company in the path are returned. Endpoint: GET /v1/companies/{company_id}/customers

Returns the emails the system recorded on behalf of the account in the path: invoice deliveries, verification, onboarding. It only reads the history; it does not send or resend anything. - **Every attempt is recorded**, not only the ones that went out: an email stopped by policy is listed with `status` `REJECTED`, and one accepted but not dispatched yet as `QUEUED`, rather than being omitted. - **Order:** by `sent_at` descending, configurable with `sort_by` / `sort_order`. - **Filters:** `type`, `status`, `recipient` and `related_entity_id`. - **`sent_at`:** the moment the message was handed over, so it is absent while an email is still `QUEUED`. - **Scope:** the account is the one named in the path; the environment is not, and comes from the credential. Endpoint: GET /v1/accounts/{account_id}/emails

Lists the invitations sent to join the account, whatever their `status`. Accepted, revoked and expired invitations stay in the list: the record is the trail of who was granted access to the account's fiscal data. Endpoint: GET /v1/accounts/{account_id}/invitations

Returns the PDF templates a NIF can be rendered with. For each one, the `code` to send as `template_type` in `PUT /v1/companies/{company_id}/invoice-customization`, plus a name and a short description translated into the language of the user the credential belongs to. The accepted values are already in the `template_type` enum; what this operation adds are the readable labels, so you do not have to show `MODERN_TABLE` to a person. The catalogue is identical for every account and every NIF, so it is not nested under one. **Closed catalogue.** This collection is fixed and bounded: it carries no `pagination`, it takes no `page`/`limit`, and every response holds the whole set. Endpoint: GET /v1/invoice-customization-options

Returns a paginated list of the invoices of this company, filterable by status, type, series, customer, date range and free text. Only the documents of the company in the path are returned. Endpoint: GET /v1/companies/{company_id}/invoices ⚠️ Fiscal guardrails — read before calling: - When an invoice can still be changed, and what to do once it cannot. (resource: beel://guardrails/invoice-state-machine) For the exhaustive rules and worked examples, call beel_docs_search.

Lists the companies (NIFs) granted to a `MEMBER` and the `access_level` of each. Empty for `OWNER` and `ADMIN`, who reach every company of the account implicitly and hold no grants. **Paginated** with the usual `page`/`limit`, and the usual defaults: without them you get the first 20 grants, not all of them. Read `data.pagination` to walk the rest. Endpoint: GET /v1/accounts/{account_id}/members/{member_id}/grants

Lists the people with access to the account, each with their `account_role` and, for `MEMBER`s, the companies (NIFs) granted to them. **Paginated** with the usual `page`/`limit`, and the usual defaults: without them you get the first 20 members, not all of them. Read `data.pagination` to walk the rest. Endpoint: GET /v1/accounts/{account_id}/members

Returns the payment provider connections of a company your account **owns or manages**, with the provider-side account each one points at and its `status`. Use it to check whether a NIF you provisioned has completed its connection. - **A NIF with no connections:** answers `200` with an empty list. - **`environment`:** Test and Live connections are independent, so only the ones living in the mode of the key you ask with are returned; this field states which. **Closed catalogue.** This collection is fixed and bounded — one entry per supported provider at most: it carries no `pagination`, it takes no `page`/`limit`, and every response holds the whole set. Endpoint: GET /v1/companies/{company_id}/payment-connections

Lists the payment events received through the payment provider connection of a NIF (company), most recent first. Use it to audit the charges that produced an invoice and to find the ones that did not. - **Scope:** events belong to the connection, not to the NIF directly. The `{provider}` segment picks the connection of the NIF in the path, and only the events of that connection are returned; an event of another NIF of the same account is never reachable from here. - **No connection:** if the NIF has none for the provider, the request returns `404`. Endpoint: GET /v1/companies/{company_id}/payment-connections/{provider}/events

Returns a paginated list of the products/services of this company, with optional filters. - **`q`:** searching is done on this collection, there is no separate search path. `q` matches the name, the code and the description, so it returns at least everything the withdrawn `GET /v1/products/search` returned, in the paginated envelope of this list. Endpoint: GET /v1/companies/{company_id}/products

Lists the recurring invoice templates of this company, with filters and pagination. Only the templates of the company in the path are returned. Endpoint: GET /v1/companies/{company_id}/recurring-invoices ⚠️ 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.

Returns the history of public API requests made by you, with any of your API keys in this environment — not only the key you are authenticating with. Only `auth_type=API_KEY` traffic is recorded. - **The axis is the person, not the individual credential:** a second key of yours sees the same history, and narrowing it to one key is a filter (`api_key_id`), not the default. - **It is still not the account's traffic:** requests made by other users of the same account, or by their API keys, are never returned. The `{account_id}` in the path authorizes the call; it does not widen what you can see. - **Environment is not a filter:** results are always scoped to the environment of the credential you authenticate with — a `beel_sk_test_*` key sees the test traffic of all your test keys, a `beel_sk_live_*` key the live traffic of all your live ones. To see the other environment, use a key from that environment. - **Cursor pagination:** navigate with the opaque `cursor` returned in `next_cursor` / `prev_cursor`; there is no jump to an arbitrary page N. - **Time window:** defaults to the last 30 days; narrow or move it with `from`/`to`. Endpoint: GET /v1/accounts/{account_id}/request-logs

Returns the invoice series of a company. - **Filters:** `active` restricts to active or inactive series — omit it and you get all of them. `document_type` filters by type and always includes the `UNASSIGNED` series, which are compatible with any type. - **Pagination (opt-in):** send `page` and/or `limit` to receive a single page plus a `data.pagination` block with the totals. Omit both and the response carries the full list in `data.series` and no `pagination` block. Endpoint: GET /v1/companies/{company_id}/series ⚠️ Fiscal guardrails — read before calling: - How invoice numbers are formed, and why numbering can never be rewritten. (resource: beel://guardrails/series-and-numbering) For the exhaustive rules and worked examples, call beel_docs_search.

Returns, for each company of the account, how many fiscal documents it has issued and when it last issued one. - **`invoice_count`:** drafts, scheduled invoices and proformas are not counted; a rectifying invoice counts as a document of its own, and a voided invoice counts only when a live rectifying invoice compensates it. - **`last_invoice_at`:** issue date of the most recent document in that same set, or `null` when there is none. - **Not a cursor:** the count is not monotonic — voiding an uncompensated invoice lowers it and moves `last_invoice_at` backwards — so do not synchronise on it. **Paginated** with the usual `page`/`limit`, and the usual defaults: without them you get the stats of the first 20 companies, not of all of them. One row per company, over the same universe and in the same order as `GET /v1/accounts/{account_id}/companies` — `search` included — so asking both with the same `page`, `limit` and `search` lines the two responses up company by company. Endpoint: GET /v1/accounts/{account_id}/companies/stats

Returns the tax regimes and percentages that Spanish law allows on an invoice. Use it to validate a rate before sending it, or to build your own picker instead of hard-coding the percentages. - **Contents:** VAT (mainland), IGIC (Canary Islands), IPSI (Ceuta and Melilla), the withholding (IRPF) percentages, the equivalence surcharge that corresponds to each VAT rate, and the exemption reasons with the classification each one implies. - **Scope:** the catalogue is the same for every credential and does not depend on any account or on any NIF, so the operation takes no identifier and works before the first NIF exists. ## VAT rates and the zero case - **VAT lists 4, 5, 10 and 21, and deliberately not 0:** under VAT (and IPSI) a 0 % is not a rate but the exemption/non-subject sentinel, and on its own it says nothing. A 0 % line is only valid together with an `exemption_reason`, which this same response publishes under `exemption_reasons`. - **IGIC does list 0:** there it is the real "Tipo Cero" and needs no reason. - **The 5 % VAT rate (RD-ley 11/2022):** kept even though it no longer applies to new operations, because correctives and late filings for those periods still need it. Endpoint: GET /v1/tax-types

Returns the delivery attempts of this subscription, newest first. Each entry records one attempt with the response it got, so a retried event appears once per attempt. - **`event_type`:** narrows the list to a single event type. - **`event_id`:** follows one event across every attempt made on it, without paging through the whole history. Endpoint: GET /v1/accounts/{account_id}/webhooks/{webhook_id}/deliveries

Returns the webhook subscriptions of the account in the path, active and inactive alike. Every member of the account sees the same list: who registered a subscription is authorship, not visibility. The signing secrets are never included. Endpoint: GET /v1/accounts/{account_id}/webhooks

Updates the editable fields of a company; the set is the one `UpdateCompanyRequest` declares. - **Immutable fields:** `nif`, `entity_type` and `legal_form`, once set. - **`legal_name`:** changing it requires the NIF to pass an AEAT census re-validation — which for a company checks the CIF only, so it cannot fail because of the name sent. ## Test credentials on a Live company Once the company is activated in Live, a test credential may only write the fields that affect how the invoice looks: `logo_url`, `invoice_accent_color`, `invoice_template_type`, `invoice_language`, `email_language` and `additional_info`. Any other field describes the real business — fiscal address, legal representative, bank details, contact data, IAE, activity start date, payment term — and answers `422 FISCAL_IDENTITY_LIVE_ONLY` from Test, since the company is a single record shared by both modes. A company not activated in Live accepts the whole body from Test, and sending a field its current value is never a change. ## What comes back The `200` returns `CompanyData` with **every field this request accepts**, under the same name and the same type — so the response is the confirmation of what was stored, and a later `GET` says the same. A field you never set comes back absent, which means "nothing stored", not "hidden". Two things live outside this body and keep their own reads: the invoice series (`GET /v1/companies/{company_id}/series`) and the rendering block, which is also served on its own by `GET /v1/companies/{company_id}/invoice-customization`. Endpoint: PATCH /v1/companies/{company_id} ⚠️ Fiscal guardrails — read before calling: - Which company an operation acts on, and how that is selected. (resource: beel://guardrails/multi-nif) For the exhaustive rules and worked examples, call beel_docs_search.

Updates only the fields present in the body, leaving every other field of the customer as it is. - **Null vs omitted:** a field sent as `null` is cleared, which is different from omitting it (see `PatchCustomerRequest`). - **Only update verb:** this is the canonical way to edit a customer. There is no `PUT` of full replacement under the company, which would clear the fields you omit. Endpoint: PATCH /v1/companies/{company_id}/customers/{customer_id}

Updates only the fields present in the body, leaving every other field of the invoice as it is. - **Status:** only a draft invoice can be modified. An issued one is amended with a corrective invoice (`POST …/{invoice_id}/corrective`) or voided. - **Series:** changing `series_id` never moves the invoice to another NIF — a series of another company is not visible from here. Endpoint: PATCH /v1/companies/{company_id}/invoices/{invoice_id} ⚠️ Fiscal guardrails — read before calling: - When an invoice can still be changed, and what to do once it cannot. (resource: beel://guardrails/invoice-state-machine) For the exhaustive rules and worked examples, call beel_docs_search.

Changes a member's `account_role` between `ADMIN` and `MEMBER`. - **`OWNER`:** not an assignable value here. An account has exactly one owner, and ownership is handed over only through `PUT /v1/accounts/{account_id}/owner`, which promotes the new owner and steps the current one down in the same operation. - **Last owner:** the account's last `OWNER` cannot be demoted. Endpoint: PATCH /v1/accounts/{account_id}/members/{member_id}

Updates only the fields present in the body, leaving every other field of the product as it is — in particular `main_tax`, `irpf_rate` and `equivalence_surcharge_rate`. - **Null vs omitted:** a field sent as `null` is cleared, which is different from omitting it (see `PatchProductRequest`). - **Only update verb:** the total replacement `PUT /v1/products/{product_id}`, which reset the omitted fields to their creation defaults, is not carried over to the canonical form. Endpoint: PATCH /v1/companies/{company_id}/products/{product_id}