--- title: "E-mail one validated invoice to one recipient" method: POST path: "/v1/send" tags: ["Invoices"] --- # E-mail one validated invoice to one recipient `POST /v1/send` ## Request - Base URL: `https://api.attestwire.com` - URL: `https://api.attestwire.com/v1/send` - Auth: HTTP bearer Attestwire sends invoices by e-mail on request; it does not operate Peppol or French-platform transmission. This generates an invoice — or takes one you already have — checks it, and e-mails it to one address through Resend (resend.com): one invoice per message, attached under its invoice number, with a subject and a short note in the invoice's language ("Rechnung {nr} von {seller}", "Facture {nr} de {seller}", "Invoice {nr} from {seller}"). WHAT IS SENT. `invoice` with `format: "xml"` sends the XML of its profile (XRechnung UBL for `xrechnung-ubl`); `format: "pdf"` sends the Factur-X / ZUGFeRD PDF (EN 16931 profile), profile `facturx-en16931` only, drawn with the `pdf` options exactly as /v1/generate draws it. `document` is a file you already have, as base64 — XML, or a Factur-X or ZUGFeRD PDF — read by the reader /v1/validate uses and attached byte for byte as sent. Nothing with a fatal finding is sent: that is a 422 with the ValidationResult. WHO IT IS FROM. `From` is this deployment's sender address, displayed as "{seller} via Attestwire". `Reply-To` is the seller's contact e-mail (BT-43), so the invoice must carry one (`400 seller_email_required`). The language is `language` if named, else the PDF page's, else the seller country's: DE and AT German, FR French, anything else English. THE FREE PLAN IS A TEST MODE: it sends only to the address the key was registered with (`403 recipient_not_allowed` otherwise), every message is marked "[TEST]" and says it is not a request for payment, and a PDF is the watermarked preview. The paid plans (Solo, Starter, Scale) send to anyone. LIMITS. 10 messages per key per UTC day on the free plan and 500 on a paid plan (`429 send_limit_exceeded`); a ceiling on the deployment's sends per UTC day across all keys, 50 unless it sets another, because the mail account is shared (`429 send_capacity_exceeded`, which says when it resets); both with `Retry-After` until 00:00 UTC. Then the per-second pace limit, and an attachment of at most 7 MB, so the message stays under the 10 MB many receiving mail servers accept. CHARGED once the mail service has accepted the message: one document. Every refusal costs nothing, and nothing is retried on your behalf. The answer is `202 Accepted`, because acceptance is all Attestwire learns: Accepted by the mail service, which delivers it and retries on its own. Attestwire is not told whether it was delivered, bounced or marked as spam, and does not store the message: keep attachment.sha256 and message_id as your record of what was sent, and ask the recipient to confirm receipt if you need to know. A retry after a timeout can send the invoice twice. Nothing about the message is stored by Attestwire; Resend processes it to deliver it and keeps its own delivery logs. Each message carries the header `X-Attestwire-Account` with the sending key's 8-character fingerprint, so an abuse report can be traced to the key. A deployment without e-mail configured answers `503 email_not_enabled`, before authentication. ## Request body - SendRequest: One recipient, and either an invoice to generate (`invoice` with `format`) or a document you already have (`document`). Any other field is refused with 400. - `to` string, email, required: One plain address, no display name. On the free plan it must be the address the key was registered with. - `invoice` InvoiceInput: The invoice as JSON: the body of POST /v1/validate (as `application/json`) and of POST /v1/generate, and the `invoice` POST /v1/parse returns. Field names map to EN 16931 business terms. The fields in `required` are the only ones the model needs; every other field and group is optional, and one you leave out is not written. Types are the model's and nothing more: the rules judge the values and report what is wrong as findings, so a value this schema allows can still fail validation. Mirrors `InvoiceInput` in @attestwire/en16931. - `profile` 'en16931' | 'xrechnung-ubl' | 'xrechnung-cii' | 'facturx-en16931' | 'peppol-bis-3' | 'auto', required: Selects the rule set, and on POST /v1/generate the syntax. Narrower profiles add rules; they never remove core ones. "auto" (POST /v1/validate and /v1/generate) has the API choose from the buyer, without any network call: a Leitweg-ID (electronic address scheme 0204, or a German buyer reference) is xrechnung-ubl; a Belgian buyer or a Peppol electronic address is peppol-bis-3; a French buyer is facturx-en16931; a German or Austrian business is xrechnung-cii, or facturx-en16931 with ?format=pdf; anything else is en16931 (facturx-en16931 with ?format=pdf). The answer names the choice and the rule in `profile_choice` and the Attestwire-Profile headers. - `invoiceNumber` string, required: BT-1 invoice number. - `issueDate` string, date, required: BT-2 issue date, ISO 8601. - `currency` string, required: BT-5 invoice currency code, ISO 4217. - `invoiceTypeCode` string: BT-3 document type code, UNTDID 1001: "380", the default, is a commercial invoice and "381" a credit note. It decides the document type: "381" makes a UBL `CreditNote` or a CII document with type code 381, from the same fields. State a credit note's amounts positively; the type code carries the direction. BR-DE-17 restricts XRechnung to 326/380/381/384/389/875/876/877. - `dueDate` string, date: BT-9 payment due date, ISO 8601. A UBL credit note carries it inside the payment means (`cac:PaymentMeans/cbc:PaymentDueDate`), so there it needs `payment`; without that group it is dropped and reported as ATW-CREDIT-NOTE-DUE-DATE-UNBOUND. - `note` string: BT-22 invoice note, free text. - `noteSubjectCode` string: BT-21 invoice note subject code, UNCL 4451. Written into the note itself as `#CODE#text`, so it only means something when `note` is set. - `buyerReference` string: BT-10 buyer reference, which XRechnung requires (BR-DE-15). A German public-sector buyer's is its Leitweg-ID. - `orderReference` string: BT-13 purchase order reference. - `salesOrderReference` string: BT-14 sales order reference: your own order number, not the buyer's. - `projectReference` string: BT-11 project reference. `UBL-CreditNote-2.1.xsd` has no element for it, so on a UBL credit note it is dropped and reported as ATW-CREDIT-NOTE-PROJECT-REFERENCE-UNBOUND. CII keeps it. - `contractReference` string: BT-12 contract reference. - `despatchAdviceReference` string: BT-16 despatch advice reference. - `receivingAdviceReference` string: BT-15 receiving advice reference. - `tenderOrLotReference` string: BT-17 tender or lot reference. - `invoicedObjectIdentifier` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from. - `value` string, required: The identifier. - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers. - `buyerAccountingReference` string: BT-19 buyer accounting reference: the buyer's cost centre or ledger account. - `taxPointDate` string, date: BT-7 value added tax point date, ISO 8601. BR-CO-03 does not allow it together with `invoicingPeriod.descriptionCode` (BT-8). - `invoicingPeriod` InvoicingPeriod: BG-14 invoicing period, or BG-26 when it is a line's `period`. The first term of each pair is the document's. - `startDate` string, date: BT-73 / BT-134 period start date, ISO 8601. - `endDate` string, date: BT-74 / BT-135 period end date, ISO 8601. - `descriptionCode` string: BT-8 value added tax point date code, UNTDID 2005 (3, 35 or 432). Document level only: ignored on a line period. BR-CO-03 does not allow it together with `taxPointDate`. - `precedingInvoices` PrecedingInvoiceReference[]: BG-3 preceding invoice references: the invoices this document corrects, credits or settles against. BR-DE-26 requires one for a corrected invoice (BT-3 = 384). A credit note is not required to carry one; leaving it out raises ATW-CREDIT-NOTE-NO-PRECEDING-INVOICE at severity `information`. - `invoiceNumber` string, required: BT-25 the number of the invoice being corrected or referenced. - `issueDate` string, date: BT-26 the issue date of that invoice, ISO 8601. - `seller` Party, required: BG-4 seller or BG-7 buyer. Where a field names two terms, the first is the seller's and the second the buyer's; a field with one term exists for the seller only. - `name` string, required: BT-27 / BT-44 name, written as both the legal name and the trading name (BT-28 / BT-45) unless `legalName` or `tradingName` says otherwise. - `vatId` string: BT-31 / BT-48 VAT identifier, with its country prefix. - `taxRegistrationId` string: BT-32 seller tax registration identifier, such as the German Steuernummer. - `legalRegistrationId` string: BT-30 / BT-47 legal registration identifier, such as an HRB number. - `legalRegistrationSchemeId` string: BT-30-1 / BT-47-1 ISO 6523 ICD scheme of the legal registration identifier. - `identifier` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from. - `value` string, required: The identifier. - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers. - `additionalLegalInformation` string: BT-33 seller additional legal information: legal form, share capital and the like. - `tradingName` string: BT-28 / BT-45 trading name, when the party trades under a name other than its legal one. - `legalName` string: BT-27 / BT-44 registered legal name, when it differs from `name`. - `address` PostalAddress, required: A postal address: BG-5 seller, BG-8 buyer or BG-12 tax representative. The terms are listed in that order. - `line1` string: BT-35 / BT-50 / BT-64 address line 1. - `line2` string: BT-36 / BT-51 / BT-65 address line 2. - `line3` string: BT-162 / BT-163 / BT-164 address line 3. - `city` string, required: BT-37 / BT-52 / BT-66 city. - `postalCode` string, required: BT-38 / BT-53 / BT-67 post code. - `countrySubdivision` string: BT-39 / BT-54 / BT-68 country subdivision: a Bundesland, a région, a county. - `countryCode` string, required: BT-40 / BT-55 / BT-69 country code, ISO 3166-1 alpha-2. - `electronicAddress` ElectronicAddress: BT-34 seller or BT-49 buyer electronic address: where the network delivers the document. Both halves are required. - `schemeId` string, required: BT-34-1 / BT-49-1 scheme identifier, from the Peppol EAS code list. - `value` string, required: BT-34 / BT-49 the address itself. - `contact` Contact: BG-6 seller contact or BG-9 buyer contact. - `name` string: BT-41 / BT-56 contact point: a person or a department. - `email` string: BT-43 / BT-58 contact email address. - `phone` string: BT-42 / BT-57 contact telephone number. - `buyer` Party, required: BG-4 seller or BG-7 buyer. Where a field names two terms, the first is the seller's and the second the buyer's; a field with one term exists for the seller only. - `name` string, required: BT-27 / BT-44 name, written as both the legal name and the trading name (BT-28 / BT-45) unless `legalName` or `tradingName` says otherwise. - `vatId` string: BT-31 / BT-48 VAT identifier, with its country prefix. - `taxRegistrationId` string: BT-32 seller tax registration identifier, such as the German Steuernummer. - `legalRegistrationId` string: BT-30 / BT-47 legal registration identifier, such as an HRB number. - `legalRegistrationSchemeId` string: BT-30-1 / BT-47-1 ISO 6523 ICD scheme of the legal registration identifier. - `identifier` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from. - `value` string, required: The identifier. - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers. - `additionalLegalInformation` string: BT-33 seller additional legal information: legal form, share capital and the like. - `tradingName` string: BT-28 / BT-45 trading name, when the party trades under a name other than its legal one. - `legalName` string: BT-27 / BT-44 registered legal name, when it differs from `name`. - `address` PostalAddress, required: A postal address: BG-5 seller, BG-8 buyer or BG-12 tax representative. The terms are listed in that order. - `line1` string: BT-35 / BT-50 / BT-64 address line 1. - `line2` string: BT-36 / BT-51 / BT-65 address line 2. - `line3` string: BT-162 / BT-163 / BT-164 address line 3. - `city` string, required: BT-37 / BT-52 / BT-66 city. - `postalCode` string, required: BT-38 / BT-53 / BT-67 post code. - `countrySubdivision` string: BT-39 / BT-54 / BT-68 country subdivision: a Bundesland, a région, a county. - `countryCode` string, required: BT-40 / BT-55 / BT-69 country code, ISO 3166-1 alpha-2. - `electronicAddress` ElectronicAddress: BT-34 seller or BT-49 buyer electronic address: where the network delivers the document. Both halves are required. - `schemeId` string, required: BT-34-1 / BT-49-1 scheme identifier, from the Peppol EAS code list. - `value` string, required: BT-34 / BT-49 the address itself. - `contact` Contact: BG-6 seller contact or BG-9 buyer contact. - `name` string: BT-41 / BT-56 contact point: a person or a department. - `email` string: BT-43 / BT-58 contact email address. - `phone` string: BT-42 / BT-57 contact telephone number. - `payee` Payee: BG-10 payee: where the money goes, when that is not the seller. - `name` string, required: BT-59 payee name. Must differ from the seller name (BR-17). - `identifier` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from. - `value` string, required: The identifier. - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers. - `legalRegistrationId` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from. - `value` string, required: The identifier. - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers. - `taxRepresentative` TaxRepresentative: BG-11 seller tax representative party. - `name` string, required: BT-62 tax representative name. - `vatId` string, required: BT-63 tax representative VAT identifier. BR-56 requires it once BG-11 exists. - `address` PostalAddress, required: A postal address: BG-5 seller, BG-8 buyer or BG-12 tax representative. The terms are listed in that order. - `line1` string: BT-35 / BT-50 / BT-64 address line 1. - `line2` string: BT-36 / BT-51 / BT-65 address line 2. - `line3` string: BT-162 / BT-163 / BT-164 address line 3. - `city` string, required: BT-37 / BT-52 / BT-66 city. - `postalCode` string, required: BT-38 / BT-53 / BT-67 post code. - `countrySubdivision` string: BT-39 / BT-54 / BT-68 country subdivision: a Bundesland, a région, a county. - `countryCode` string, required: BT-40 / BT-55 / BT-69 country code, ISO 3166-1 alpha-2. - `vatScenario` 'domestic' | 'intra-eu-goods' | 'intra-eu-services' | 'export' | 'small-business-exemption': What happened, in business terms, for every line, document level allowance and charge that does not say otherwise: the engine writes the VAT category (BT-151, BT-95, BT-102), the rate and the exemption reason (BT-120, BT-121) from it. "domestic": a taxed sale inside the seller's own country — category S at the rate you state in `vatRate`, which is never guessed. "intra-eu-goods": goods shipped to a VAT-registered business in another EU member state — K, rate 0, VATEX-EU-IC; the invoice also needs both parties' VAT identifiers, `deliverTo.countryCode` and a delivery date or invoicing period. "intra-eu-services": a service to a business in another EU member state, which accounts for the VAT itself (reverse charge) — AE, rate 0, VATEX-EU-AE; needs both VAT identifiers. "export": goods leaving the EU — G, rate 0, VATEX-EU-G; needs the seller's VAT identifier. "small-business-exemption": the seller does not charge VAT under its small-business scheme, Germany's § 19 UStG or France's franchise en base — E, rate 0, with the wording each country prescribes; a seller elsewhere is refused with ATW-VAT-SCENARIO-UNSUPPORTED. The exemption text is written in German for a seller in DE or AT, in French for FR, in English otherwise. It is not a tax determination: you decide which scenario applies, and the engine only writes its codes. An item's own `vatScenario` or `vatCategory` overrides this default. The document is byte for byte the one the explicit codes produce. - `lines` InvoiceLine[], required: BG-25 invoice lines, at least one (BR-16). An empty list is answered with that finding. - `id` string, required: BT-126 invoice line identifier. - `description` string, required: BT-153 item name. - `longDescription` string: BT-154 item description, when it should say more than the item name. - `quantity` number, required: BT-129 invoiced quantity. - `unitCode` string, required: BT-130 unit of measure code, UN/ECE Recommendation 20. - `unitPrice` number, required: BT-146 item net price. - `grossUnitPrice` number: BT-148 item gross price, before the BT-147 price discount. - `priceDiscount` number: BT-147 item price discount: the difference between BT-148 and BT-146. - `baseQuantity` number: BT-149 item price base quantity, 1 when absent. - `vatCategory` 'S' | 'Z' | 'E' | 'AE' | 'K' | 'G' | 'O' | 'L' | 'M', required: BT-151 invoiced item VAT category code, UNCL 5305: S standard rate, Z zero rated, E exempt, AE reverse charge, K intra-community supply, G export outside the EU, O not subject to VAT, L IGIC (Canary Islands), M IPSI (Ceuta and Melilla). Left out, it comes from the line's `vatScenario` or the invoice's. - `vatRate` number: BT-152 invoiced item VAT rate, in percent. - `vatScenario` 'domestic' | 'intra-eu-goods' | 'intra-eu-services' | 'export' | 'small-business-exemption': What happened on this line, instead of its VAT code: the engine writes `vatCategory`, the rate (except for "domestic", whose rate you give in `vatRate`) and the exemption reason from it. It overrides the invoice's `vatScenario`. A `vatCategory` stated beside it must be the one it stands for: disagreeing is the fatal ATW-VAT-SCENARIO-CONFLICT. With a scenario, `vatCategory` may be left out of the request although this schema lists it as required (the schema describes the explicit model, which POST /v1/parse returns); the response reports each code it filled in as ATW-VAT-SCENARIO-APPLIED, at severity information. "domestic": a taxed sale inside the seller's own country — category S at the rate you state in `vatRate`, which is never guessed. "intra-eu-goods": goods shipped to a VAT-registered business in another EU member state — K, rate 0, VATEX-EU-IC; the invoice also needs both parties' VAT identifiers, `deliverTo.countryCode` and a delivery date or invoicing period. "intra-eu-services": a service to a business in another EU member state, which accounts for the VAT itself (reverse charge) — AE, rate 0, VATEX-EU-AE; needs both VAT identifiers. "export": goods leaving the EU — G, rate 0, VATEX-EU-G; needs the seller's VAT identifier. "small-business-exemption": the seller does not charge VAT under its small-business scheme, Germany's § 19 UStG or France's franchise en base — E, rate 0, with the wording each country prescribes; a seller elsewhere is refused with ATW-VAT-SCENARIO-UNSUPPORTED. The exemption text is written in German for a seller in DE or AT, in French for FR, in English otherwise. It is not a tax determination: you decide which scenario applies, and the engine only writes its codes. - `note` string: BT-127 invoice line note. - `objectIdentifier` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from. - `value` string, required: The identifier. - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers. - `buyerAccountingReference` string: BT-133 invoice line buyer accounting reference. - `period` InvoicingPeriod: BG-14 invoicing period, or BG-26 when it is a line's `period`. The first term of each pair is the document's. - `startDate` string, date: BT-73 / BT-134 period start date, ISO 8601. - `endDate` string, date: BT-74 / BT-135 period end date, ISO 8601. - `descriptionCode` string: BT-8 value added tax point date code, UNTDID 2005 (3, 35 or 432). Document level only: ignored on a line period. BR-CO-03 does not allow it together with `taxPointDate`. - `orderLineReference` string: BT-132 referenced purchase order line reference. - `allowances` LineAllowanceCharge[]: BG-27 invoice line allowances: discounts on this line only. - `amount` number, required: BT-136 / BT-141 amount, always positive. - `baseAmount` number: BT-137 / BT-142 base amount. - `percentage` number: BT-138 / BT-143 percentage. - `reason` string: BT-139 / BT-144 reason, free text. - `reasonCode` string: BT-140 / BT-145 reason code: UNCL 5189 for an allowance, UNCL 7161 for a charge. - `charges` LineAllowanceCharge[]: BG-28 invoice line charges: surcharges on this line only. - `amount` number, required: BT-136 / BT-141 amount, always positive. - `baseAmount` number: BT-137 / BT-142 base amount. - `percentage` number: BT-138 / BT-143 percentage. - `reason` string: BT-139 / BT-144 reason, free text. - `reasonCode` string: BT-140 / BT-145 reason code: UNCL 5189 for an allowance, UNCL 7161 for a charge. - `sellerItemId` string: BT-155 item seller's identifier. - `buyerItemId` string: BT-156 item buyer's identifier. - `standardItemId` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from. - `value` string, required: The identifier. - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers. - `itemClassifications` ItemClassification[]: BT-158 item classification identifiers. - `code` string, required: BT-158 the classification code. - `schemeId` string, required: BT-158-1 the scheme it is drawn from, UNTDID 7143. - `schemeVersion` string: BT-158-2 the version of that scheme. - `originCountryCode` string: BT-159 item country of origin, ISO 3166-1 alpha-2. - `itemAttributes` ItemAttribute[]: BG-32 item attributes: name and value pairs describing the item. - `name` string, required: BT-160 item attribute name. - `value` string, required: BT-161 item attribute value. - `allowances` DocumentAllowanceCharge[]: BG-20 document level allowances: discounts on the whole invoice. - `amount` number, required: BT-92 / BT-99 amount, always positive. - `baseAmount` number: BT-93 / BT-100 base amount. - `percentage` number: BT-94 / BT-101 percentage. - `vatCategory` 'S' | 'Z' | 'E' | 'AE' | 'K' | 'G' | 'O' | 'L' | 'M', required: BT-95 / BT-102 VAT category code, UNCL 5305: S standard rate, Z zero rated, E exempt, AE reverse charge, K intra-community supply, G export outside the EU, O not subject to VAT, L IGIC (Canary Islands), M IPSI (Ceuta and Melilla). Left out, it comes from the entry's `vatScenario` or the invoice's. - `vatRate` number: BT-96 / BT-103 VAT rate, in percent. - `vatScenario` 'domestic' | 'intra-eu-goods' | 'intra-eu-services' | 'export' | 'small-business-exemption': What happened, instead of the VAT code of this allowance or charge: the engine writes `vatCategory`, the rate (except for "domestic", whose rate you give in `vatRate`) and the exemption reason from it. It overrides the invoice's `vatScenario`. A `vatCategory` stated beside it must be the one it stands for: disagreeing is the fatal ATW-VAT-SCENARIO-CONFLICT. With a scenario, `vatCategory` may be left out of the request although this schema lists it as required (the schema describes the explicit model, which POST /v1/parse returns); the response reports each code it filled in as ATW-VAT-SCENARIO-APPLIED, at severity information. "domestic": a taxed sale inside the seller's own country — category S at the rate you state in `vatRate`, which is never guessed. "intra-eu-goods": goods shipped to a VAT-registered business in another EU member state — K, rate 0, VATEX-EU-IC; the invoice also needs both parties' VAT identifiers, `deliverTo.countryCode` and a delivery date or invoicing period. "intra-eu-services": a service to a business in another EU member state, which accounts for the VAT itself (reverse charge) — AE, rate 0, VATEX-EU-AE; needs both VAT identifiers. "export": goods leaving the EU — G, rate 0, VATEX-EU-G; needs the seller's VAT identifier. "small-business-exemption": the seller does not charge VAT under its small-business scheme, Germany's § 19 UStG or France's franchise en base — E, rate 0, with the wording each country prescribes; a seller elsewhere is refused with ATW-VAT-SCENARIO-UNSUPPORTED. The exemption text is written in German for a seller in DE or AT, in French for FR, in English otherwise. It is not a tax determination: you decide which scenario applies, and the engine only writes its codes. - `reason` string: BT-97 / BT-104 reason, free text. - `reasonCode` string: BT-98 / BT-105 reason code: UNCL 5189 for an allowance, UNCL 7161 for a charge. - `charges` DocumentAllowanceCharge[]: BG-21 document level charges: freight, packing, surcharges. - `amount` number, required: BT-92 / BT-99 amount, always positive. - `baseAmount` number: BT-93 / BT-100 base amount. - `percentage` number: BT-94 / BT-101 percentage. - `vatCategory` 'S' | 'Z' | 'E' | 'AE' | 'K' | 'G' | 'O' | 'L' | 'M', required: BT-95 / BT-102 VAT category code, UNCL 5305: S standard rate, Z zero rated, E exempt, AE reverse charge, K intra-community supply, G export outside the EU, O not subject to VAT, L IGIC (Canary Islands), M IPSI (Ceuta and Melilla). Left out, it comes from the entry's `vatScenario` or the invoice's. - `vatRate` number: BT-96 / BT-103 VAT rate, in percent. - `vatScenario` 'domestic' | 'intra-eu-goods' | 'intra-eu-services' | 'export' | 'small-business-exemption': What happened, instead of the VAT code of this allowance or charge: the engine writes `vatCategory`, the rate (except for "domestic", whose rate you give in `vatRate`) and the exemption reason from it. It overrides the invoice's `vatScenario`. A `vatCategory` stated beside it must be the one it stands for: disagreeing is the fatal ATW-VAT-SCENARIO-CONFLICT. With a scenario, `vatCategory` may be left out of the request although this schema lists it as required (the schema describes the explicit model, which POST /v1/parse returns); the response reports each code it filled in as ATW-VAT-SCENARIO-APPLIED, at severity information. "domestic": a taxed sale inside the seller's own country — category S at the rate you state in `vatRate`, which is never guessed. "intra-eu-goods": goods shipped to a VAT-registered business in another EU member state — K, rate 0, VATEX-EU-IC; the invoice also needs both parties' VAT identifiers, `deliverTo.countryCode` and a delivery date or invoicing period. "intra-eu-services": a service to a business in another EU member state, which accounts for the VAT itself (reverse charge) — AE, rate 0, VATEX-EU-AE; needs both VAT identifiers. "export": goods leaving the EU — G, rate 0, VATEX-EU-G; needs the seller's VAT identifier. "small-business-exemption": the seller does not charge VAT under its small-business scheme, Germany's § 19 UStG or France's franchise en base — E, rate 0, with the wording each country prescribes; a seller elsewhere is refused with ATW-VAT-SCENARIO-UNSUPPORTED. The exemption text is written in German for a seller in DE or AT, in French for FR, in English otherwise. It is not a tax determination: you decide which scenario applies, and the engine only writes its codes. - `reason` string: BT-97 / BT-104 reason, free text. - `reasonCode` string: BT-98 / BT-105 reason code: UNCL 5189 for an allowance, UNCL 7161 for a charge. - `paymentTerms` string: BT-20 payment terms, free text. - `payment` PaymentInstructions: BG-16 payment instructions. Required for XRechnung profiles by BR-DE-1. - `meansCode` string, required: BT-81 payment means type code, UNTDID 4461: "58" SEPA credit transfer, "30" credit transfer, "59" SEPA direct debit, "48" card, "57" standing order, "97" clearing. Left out of a request, it is inferred from the account, as the engine's `applyDefaults` does: "59" for a direct debit mandate in euro and "49" in another currency, else "58" for an IBAN in the SEPA scheme paid in euro and "30" for any other IBAN; the response reports it as ATW-PAYMENT-MEANS-INFERRED, at severity information. - `meansName` string: BT-82 payment means text. - `iban` string: BT-84 payment account identifier (BG-17): the IBAN, for a credit transfer. - `accountName` string: BT-85 payment account name (BG-17). - `bic` string: BT-86 payment service provider identifier (BG-17): the BIC. - `remittanceInformation` string: BT-83 remittance information: the payment reference. - `card` PaymentCard: BG-18 payment card information. - `primaryAccountNumber` string, required: BT-87 payment card primary account number: at most its first six and last four digits. BR-51 warns above ten characters; never put a full card number on an invoice. - `holderName` string: BT-88 payment card holder name. - `directDebit` DirectDebit: BG-19 direct debit information. - `mandateReference` string: BT-89 mandate reference identifier. - `creditorIdentifier` string: BT-90 bank assigned creditor identifier: the SEPA creditor identifier. Written as the seller's identifier with scheme "SEPA", where BR-DE-30 looks for it. - `debitedAccount` string: BT-91 debited account identifier: the payer's IBAN. Required by BR-DE-31. - `supportingDocuments` SupportingDocument[]: BG-24 additional supporting documents. - `reference` string, required: BT-122 supporting document reference. - `description` string: BT-123 supporting document description. - `externalUri` string: BT-124 external document location: a URL. - `attachment` EmbeddedAttachment: BT-125 attached document, embedded in the invoice. - `filename` string, required: BT-125-2 attached document filename. Must be unique across the invoice (BR-DE-22). - `mimeCode` string, required: BT-125-1 attached document MIME code. BR-CL-24 admits only application/pdf, image/png, image/jpeg, text/csv, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet and application/vnd.oasis.opendocument.spreadsheet. - `content` string, required: BT-125 the document bytes, base64-encoded. Written as given, not re-encoded. - `deliveryDate` string, date: BT-72 actual delivery date, ISO 8601. Required with BT-80 by BR-IC-11 for category K. On XRechnung profiles, an invoice with no time of supply at all (no BT-72, no `invoicingPeriod`, no line `period`) raises BR-DE-TMP-32 at severity `information`. - `deliverTo` DeliverToAddress: BG-15 deliver-to address. Only the country code is required by the model; XRechnung also requires the city and post code once the group is present. - `line1` string: BT-75 deliver-to address line 1. - `line2` string: BT-76 deliver-to address line 2. - `city` string: BT-77 deliver-to city. Mandatory under XRechnung once BG-15 is present. - `postalCode` string: BT-78 deliver-to post code. Mandatory under XRechnung once BG-15 is present. - `countrySubdivision` string: BT-79 deliver-to country subdivision. - `countryCode` string, required: BT-80 deliver-to country code, ISO 3166-1 alpha-2. - `deliverToName` string: BT-70 deliver-to party name. - `deliverToLocationId` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from. - `value` string, required: The identifier. - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers. - `vatAccountingCurrency` string: BT-6 VAT accounting currency, ISO 4217, when VAT is reported in a currency other than BT-5. Supplying it obliges you to supply `taxAmountInAccountingCurrency` (BR-53). - `taxAmountInAccountingCurrency` number: BT-111 invoice total VAT amount in the VAT accounting currency. It depends on the exchange rate the tax authority requires for the tax point, which is not on the invoice, so it cannot be derived: you supply it. - `paidAmount` number: BT-113 paid amount: a prepayment or deposit already received. It is subtracted from the amount due (BT-115). - `roundingAmount` number: BT-114 rounding amount, added to the total to produce a payable round figure. - `vatExemptionReasons` object: BT-120 VAT exemption reason text, keyed by VAT category, such as `{"E": "…"}`. Defaults are applied for AE, K, G and O; category E has no standard text, so BR-E-10 requires you to supply one. - `vatExemptionReasonCodes` object: BT-121 VAT exemption reason code from the CEF VATEX list, keyed by VAT category. - `declaredTotals` DeclaredTotals: Totals as someone else computed them, checked against the computed ones under BR-CO-10/11/12/13/14/15/16. Generation always writes the computed values: these exist so you can catch a mismatch in your own accounting system before a tax authority does, and omitting one is never an error. The readers (POST /v1/parse, and POST /v1/validate with a document) also record here what a document states, including the fields described as set by the readers, which a caller building the model leaves out. On that path a document must state its totals: one that omits BT-106, BT-109, BT-112 or BT-115 fails BR-12, BR-13, BR-14 or BR-15, and one that states a total that cannot be read as a number fails ATW-DECLARED-TOTAL-NOT-A-NUMBER. - `syntax` 'ubl' | 'cii': Set by the readers: the syntax the document was read from. It decides how BR-S-08 and its per-category siblings compare the stated taxable amount: exactly in CII, within ±1 in UBL. - `taxTotalsInInvoiceCurrency` number: Set by the readers: how many VAT totals carry the invoice currency (BT-5). BR-CO-15 requires exactly one. - `specificationIdentifier` string: BT-24 specification identifier as the document states it, trimmed; empty when absent. Set by the readers, so BR-01 can be judged. - `lineNetAmounts` number[]: BT-131 invoice line net amounts as each line states them, in document order; null where a line states none. Set by the readers. - `subtotals` DeclaredTaxSubtotal[]: BG-23 VAT breakdown as the document states it, in document order. Set by the readers. - `category` 'S' | 'Z' | 'E' | 'AE' | 'K' | 'G' | 'O' | 'L' | 'M': BT-118 VAT category code, as written. - `rate` number: BT-119 VAT category rate, as written. - `taxableAmount` number: BT-116 VAT category taxable amount, as written. - `taxAmount` number: BT-117 VAT category tax amount, as written. - `lineExtensionAmount` number: BT-106 sum of invoice line net amounts. - `allowanceTotalAmount` number: BT-107 sum of allowances on document level. - `chargeTotalAmount` number: BT-108 sum of charges on document level. - `taxExclusiveAmount` number: BT-109 invoice total amount without VAT. - `taxAmount` number: BT-110 invoice total VAT amount. - `taxInclusiveAmount` number: BT-112 invoice total amount with VAT. - `payableAmount` number: BT-115 amount due for payment. - `defects` DeclaredTotalDefect[]: Set by the readers: document totals the document was supposed to state and did not state readably, one entry per term. On the JSON model an omitted total means "compute it" and is never a defect. - `key` 'lineExtensionAmount' | 'allowanceTotalAmount' | 'chargeTotalAmount' | 'taxExclusiveAmount' | 'taxAmount' | 'taxInclusiveAmount' | 'payableAmount' | 'taxAmountInAccountingCurrency', required: Which total it is, as a key of DeclaredTotals. `taxAmountInAccountingCurrency` names BT-111, which the model carries on the invoice itself. - `field` string, required: The business term, such as BT-115. - `state` 'absent' | 'empty' | 'unreadable', required: Why it could not be read: `absent` fails a BR presence rule, while `empty` and `unreadable` fail XML Schema validation at the official validator before any business rule, and this API reports them as ATW-DECLARED-TOTAL-NOT-A-NUMBER. - `text` string: What the element held, verbatim, cut at 200 characters. Only for `unreadable`. - `xpath` string, required: Where the value is in the document, or where it should have been. - `overPrecise` OverPreciseAmount[]: Set by the readers: amounts the document wrote with more than two decimal places, in document order, which the BR-DEC rules report. - `field` string, required: The business term, which selects the BR-DEC rule. - `decimals` number, required: Digits after the decimal point, trailing zeros included. - `text` string, required: The amount exactly as the document writes it. - `xpath` string, required: Where it was found. - `line` number: 1-based invoice line, for a line-level term (BT-131). - `group` number: 1-based VAT breakdown group, for BT-116 and BT-117. - `format` 'xml' | 'pdf': Required with `invoice`: `xml` sends the XML of its profile, `pdf` the Factur-X / ZUGFeRD PDF (profile `facturx-en16931` only). Refused with `document`, which is sent as what it is. - `pdf` PdfOptions: Options for the page of the Factur-X / ZUGFeRD PDF (`?format=pdf`). Every one is optional; an unknown name is refused with 400 rather than ignored. - `language` 'en' | 'de' | 'fr': The language of the page: its labels, and the way it formats numbers and dates. Default: the seller country's — DE and AT German, FR French, anything else English. The invoice's own text (names, descriptions, notes) and the embedded XML are the same in every language. Query parameter: `language`. - `logo` string: A PNG or baseline JPEG as a data URL (`data:image/png;base64,…` or `data:image/jpeg;base64,…`), at most 256 KB and 2000 pixels on either side, in RGB or greyscale. It is printed in the top-left corner of the first page, scaled to fit 150 × 50 points; a PNG keeps its transparency. About 625 × 210 pixels is already 300 dpi there, and a larger PNG only costs time to decode. Refused with 400: a CMYK or progressive JPEG, an interlaced PNG, or any other kind of file. Body only. - `paymentQr` boolean: The EPC payment QR code ("GiroCode"), printed beside the payment details so a banking app can fill in the transfer: payee, IBAN, amount due and reference. Default: printed whenever the invoice can carry one — currency EUR, payment means 30, 42 or 58 (credit transfer), a valid IBAN, an amount due from 0.01 EUR, and not a credit note — and left out otherwise. `false` leaves it out; `true` requires it, and an invoice that cannot carry it is then a 400 that says why. The reference in the code is the payment reference (BT-83), or else the invoice number. Query parameter: `payment_qr=true|false`. - `paymentLink` string, uri: An https:// address where the invoice can be paid online, such as a payment page from your payment provider. It is printed under the payment details and is clickable in the PDF (a link annotation, which PDF/A permits; no script). At most 500 characters, no user name or password. It is on the page only: EN 16931 has no field for it, so the embedded XML does not carry it. Query parameter: `payment_link` (URL-encoded). - `document` string, byte: An invoice document you already have — XML, or a Factur-X or ZUGFeRD PDF — as base64. At most 7 MB once decoded. Read and judged as /v1/validate reads a document, and attached byte for byte. Not with `invoice`. - `language` 'en' | 'de' | 'fr': The language of the subject and the note. Default: the language of the attached PDF's page, when a PDF is attached, else the seller country's (DE and AT German, FR French, anything else English). ## Response `202` The mail service accepted the message. Not a delivery receipt: see `delivery`. - SendAccepted: The mail service accepted the message. `delivery` says what that does not mean. - `status` 'accepted', required - `message_id` string, required: The mail service's id for the message. - `to` string, email, required - `from` object, required - `email` string, email, required - `name` string, required: "{seller} via Attestwire". - `reply_to` string, email, required: The seller's contact e-mail (BT-43). - `subject` string, required - `language` 'en' | 'de' | 'fr', required - `test_mode` boolean, required: A free key's message: sent to its own address and marked as a test. - `source` 'generated' | 'document', required: `generated` from `invoice`, or a `document` sent as it came. - `format` 'xml' | 'pdf', required - `profile` string, nullable, required: The profile the invoice was judged under. - `attachment` object, required - `filename` string, required - `content_type` 'application/xml' | 'application/pdf', required - `bytes` integer, required - `sha256` string, required: The attachment's SHA-256: keep it as your record of what was sent. - `warnings` TeachingError[], required - `rule` string, required: The rule id, as the KoSIT validator prints it: BR-*, BR-DE-*, PEPPOL-EN16931-R*. `ATW-*` is a check of this validator's own rather than the regulation's. `AW-*` is not a rule at all: see above. - `field` union, required: Business term(s) the rule constrains. - string - string[] - `severity` 'fatal' | 'warning' | 'information', required: The reference validators' own three levels. `fatal` rejects the document; `warning` does not; `information` is advisory — KoSIT raises it and then accepts the invoice. - `message` string, required - `fix` string, required - `xpath` string: Where the element is. For a JSON invoice, its place in the UBL this API would generate. For an XML document, its path in that document as written when it is there, otherwise where it belongs, in the document's own syntax. - `docsUrl` string, uri: Where the rule is explained. On every finding except an `AW-` one, which is not a rule and has no page. - `example` string - `location` SourceLocation: Only on findings for a document, and not on an `AW-` one, which is about the whole document. The line and column of the element in the document that was sent. When the element is missing, or several could be meant and nothing says which, `exact` is false and this is the nearest enclosing element that is there. - `line` integer, required - `column` integer, required: Of the start tag, in UTF-16 code units. - `path` string, required: The element's path, with the document's own prefixes. - `exact` boolean, required - `attachment` string: Only when a PDF was sent: the name of the attachment the XML was read from. `line` and `column` are then in that XML, not in the PDF. - `information` TeachingError[], required - `rule` string, required: The rule id, as the KoSIT validator prints it: BR-*, BR-DE-*, PEPPOL-EN16931-R*. `ATW-*` is a check of this validator's own rather than the regulation's. `AW-*` is not a rule at all: see above. - `field` union, required: Business term(s) the rule constrains. - string - string[] - `severity` 'fatal' | 'warning' | 'information', required: The reference validators' own three levels. `fatal` rejects the document; `warning` does not; `information` is advisory — KoSIT raises it and then accepts the invoice. - `message` string, required - `fix` string, required - `xpath` string: Where the element is. For a JSON invoice, its place in the UBL this API would generate. For an XML document, its path in that document as written when it is there, otherwise where it belongs, in the document's own syntax. - `docsUrl` string, uri: Where the rule is explained. On every finding except an `AW-` one, which is not a rule and has no page. - `example` string - `location` SourceLocation: Only on findings for a document, and not on an `AW-` one, which is about the whole document. The line and column of the element in the document that was sent. When the element is missing, or several could be meant and nothing says which, `exact` is false and this is the nearest enclosing element that is there. - `line` integer, required - `column` integer, required: Of the start tag, in UTF-16 code units. - `path` string, required: The element's path, with the document's own prefixes. - `exact` boolean, required - `attachment` string: Only when a PDF was sent: the name of the attachment the XML was read from. `line` and `column` are then in that XML, not in the PDF. - `findings_truncated` FindingsTruncated: Present ONLY when a findings array was truncated, and absent — not null, not zeroed — otherwise. Each of `errors`, `warnings` and `information` is capped independently; past the cap the array is cut and this object states what was left out. `valid` still reflects the whole document: truncation changes what is printed, never the verdict. Reaching the cap takes a hundred-plus invoice lines on which every field is wrong, and at that scale the errors are systematic — every distinct problem in the document already appears in what you were given. Treat it as a hint to fix the pattern and re-validate, not as an error. - `total` integer, required: Findings the engine produced, across all three severities. - `returned` integer, required: Findings actually listed in this response. - `cap` integer, required: The per-severity cap this deployment applied. - `by_severity` object, required: Per-array totals, so you can see which one overflowed. - `errors` TruncationCount, required - `total` integer, required - `returned` integer, required - `warnings` TruncationCount, required - `total` integer, required - `returned` integer, required - `information` TruncationCount, required - `total` integer, required - `returned` integer, required - `note` string, required: Prose explanation, safe to show a user or an agent verbatim. - `delivery` string, required: Accepted by the mail service, which delivers it and retries on its own. Attestwire is not told whether it was delivered, bounced or marked as spam, and does not store the message: keep `attachment.sha256` and `message_id` as your record of what was sent, and ask the recipient to confirm receipt if you need to know. - `provenance` Provenance, required: What ran. Present on every metered response — POST /v1/validate and POST /v1/parse, JSON body or XML document, and the JSON envelope of POST /v1/generate including the `422` it returns for an invoice it will not emit. WHY IT EXISTS. Pin `@attestwire/en16931` and your CI gets the same answer for the same invoice forever; the hosted API always runs the current rule set, because a compliance service that froze its rules would be answering last quarter's regulation. Both are correct and the difference used to be invisible — a `valid: false` looked identical whether your invoice had changed or our rules had. This says which. The one metered response WITHOUT it is `/v1/generate?format=xml`, which returns the document alone: an XML file has nowhere to put this, and this API does not write its own metadata into a customer's tax document. - `engine` string, required: The npm package every compliance decision on this API comes from. Install this package at `engine_version` and you have the build that judged your document. - `engine_version` string, required - `ruleset` string, required: The standard and our build of it, as one identifier to quote. - `profile` string, nullable, required: The CIUS that ACTUALLY ran, read from the result rather than from your request: a body naming no profile is judged as `en16931`, and this is where you see that. `null` when there was no verdict to read it from. - `kosit_conformance` KositConformance, required: When the official KoSIT validator was last run against this engine's committed fixtures, and with what. **NOTHING IS SENT TO KoSIT WHEN YOU CALL US.** This is a dated record of a check we ran on release, not a per-call verification, and it says nothing about YOUR document. - `recorded` string, date, required: The date of the last recorded full fixture run. - `validator` string, required: Version of the KoSIT standalone validator used. - `configuration` string, required: Version of the XRechnung validator configuration used. - `configuration_published` string, date, required: The date that configuration was published by KoSIT. ## Other responses - `400`: `bad_request` — the body is not the JSON object this takes: a missing or unknown field, `invoice` and `document` both or neither, a missing `format`, a `document` that is not base64, a PDF option that is wrong, or an invoice the rule engine cannot read. `invalid_email` — `to` is not one plain address. `seller_email_required` — the invoice has no seller contact e-mail (BT-43) to reply to. `unsupported_profile` — `format: "pdf"` with a profile other than `facturx-en16931`. A `document` can also meet `xml_malformed`, `xml_rejected` and `pdf_unreadable`, as on /v1/validate. Nothing is sent or charged; the `X-RateLimit-*` set is present when the refusal came after the quota was read. - `401`: Missing or unknown API key. - `403`: The free plan sends only to the address the key was registered with, as a test. Nothing was sent or charged. - `410`: The key presented was retired by an earlier rotation. Its replacement is the live credential; this one is permanently gone, so retrying with it cannot work. Every authenticated endpoint answers this, not just /v1/keys/rotate. - `413`: The request is over 10 MB, or the attachment is over 7 MB. Nothing was sent or charged. - `415`: A `document` that is not an invoice document the reader takes: `unsupported_syntax`, as on /v1/validate. Nothing was sent or charged. - `422`: The invoice has a fatal finding, so nothing was sent and nothing was charged. The body is the ValidationResult /v1/validate gives. - `429`: Four codes. `quota_exceeded` and `rate_limited`, as on every metered route. `send_limit_exceeded`: this key has sent its messages for the UTC day. `send_capacity_exceeded`: the day's sending capacity is used up for everybody — this deployment's ceiling across all keys (50 a day unless it sets another), or the shared mail account's own day or month; the message says which and when it resets. Both carry `Retry-After` in seconds until 00:00 UTC, except a used-up month, which a day does not clear. Nothing is sent or charged. - `500`: Something threw before the message was handed over. Nothing was sent or charged. `generation_failed` comes from this route and carries the quota headers; `uncaught` comes from the route-wide handler. - `502`: The mail service (Resend) refused the message as invalid, or never confirmed it — a timeout or a lost connection, after which the message may or may not have gone. The message says which. Nothing was charged, and nothing is retried for you: after an unconfirmed send, ask the recipient before sending again. - `503`: `email_not_enabled` — this deployment has no e-mail delivery configured; answered before authentication. `email_unavailable` — the mail service is taking too many messages a second, is down, or refused this deployment's sending account (an operator's fault, logged). Nothing is sent or charged, and nothing is retried for you. --- [API](https://skmtc.dev/attestwire/apis/attestwire-api.md) · [All operations](https://skmtc.dev/attestwire/apis/attestwire-api/llms.txt) · [OpenAPI document](https://skmtc.dev/attestwire/apis/attestwire-api/revisions/0036f8e043b2?raw)