# CodeB eForms Server - full text (English, then German) Source: https://www.form-provider.com - Updated: 2026-10-12 --- # CodeB eForms Server: One form. PDF and HTML. Signed and delivered. URL: https://www.form-provider.com/en/index.html CodeB eForms Server is a web-based form platform: you design a form once in the browser, and the server publishes it as fillable PDF, responsive HTML and static HTML. Every submission comes back as a sealed PDF plus machine-readable XML, by e-mail. No programming, no app to install. Runs in your own data centre on Windows Server and IIS, or hosted by Aloaha. Formerly Aloaha eForms Server, made by Aloaha Limited in Malta. ## In short - What: a web-based eForms server. One design in the browser becomes a fillable PDF (AcroForm), responsive HTML and static HTML. - Output: every submission is a sealed PDF (SHA-512 server signature, optional RFC 3161 timestamp) plus XML data, delivered by e-mail. - Extras: handwritten and X.509 signatures, ZUGFeRD / XRechnung e-invoices, EU Digital Identity Wallet sign-in, REST API and webhooks. - Where: in your own data centre (Windows Server, IIS, .NET Framework 4.7.2) or hosted by Aloaha Limited, Malta (EU). ## What the eForms Server does CodeB eForms Server turns paper and PDF forms into online forms that work on every device. Form designers build the form in a browser-based WYSIWYG editor. Citizens, customers or staff fill it in on a phone, a desktop browser or in Adobe Reader. The server checks the input, renders the result and sends it to the person who submitted it and to the business owner of the form. It is built for public administration, insurers, property and legal offices, universities and companies that need forms with a reliable paper trail: signed, timestamped and readable by people and by software. ## What you get The main building blocks. Each one is described in detail on its own page. - **Browser-based form designer**: Place text fields, check boxes, radio buttons, drop-down lists, images, lines and signature fields by drag and drop. Set fonts, colours and validation rules. - **PDF and HTML from one design**: Every released form exists as dynamic PDF, responsive HTML and static HTML. The server picks the right format for the device. - **Handwritten and X.509 signatures**: Sign with finger or mouse; the server seals the result. Fields named esignature become PDF signature fields for certificates and smart cards. - **E-mail delivery with XML data**: The submitter gets the sealed PDF, the form owner gets the PDF plus the data as XML. Mail texts are templates per language. - **ZUGFeRD and Factur-X**: Turn invoice forms into EN 16931 e-invoices: PDF/A-3 with embedded XML, created automatically on submission. - **Users, groups and sign-in**: Roles for administrators, designers and guests, form groups, and sign-in with your Aloaha or CodeB account (OpenID Connect), including passkeys and the EU Digital Identity Wallet. ## How a form goes live 1. Design. Create a new form or clone an existing one, place the fields and set validation rules in the online designer. 2. Preview and release. Check the PDF preview, then release the form. The server renders the dynamic PDF and both HTML versions and e-mails you when they are ready. 3. Share a link. Put the form link on your website, in an e-mail or on a QR code. No plug-in and no app are needed. 4. Receive submissions. Each submission is sealed as PDF and sent by e-mail together with the XML data, ready for your back office. ## Privacy by design The eForms Server does not keep a database of submitted forms. A submission is turned into a sealed PDF and XML, delivered by e-mail and then removed from the server. If you need a server-side copy, an optional encrypted archive keeps password-protected PDFs that can only be opened with the submission ID. Because you can run the server in your own data centre, form data never has to leave your infrastructure. ## Own eForms server or form-builder service? What differs between running the CodeB eForms Server and a typical hosted form-builder service. The right choice depends on your data, your documents and your processes. | Question | CodeB eForms Server | Typical form-builder service | |---|---|---| | Where do the data live? | In your own data centre, or on a server hosted by Aloaha in the EU (Malta). | On the provider's cloud. | | What does the submitter get? | A sealed PDF of exactly the form they filled in. | Usually a confirmation e-mail or web page. | | Paper and PDF layout | The form keeps the layout of the paper or PDF original, plus a responsive version for phones. | Usually a web-only layout. | | Signatures | Handwritten signature sealed by the server; X.509 signature fields for certificates and smart cards. | Often a drawn signature image or an add-on. | | E-invoices | ZUGFeRD / Factur-X and XRechnung from a form or through the API. | Rarely built in. | | Identity | Sign-in with OpenID Connect, passkeys and the EU Digital Identity Wallet; forms pre-filled with verified data. | Varies. | | Integration | REST API (OpenAPI 3.1) with OAuth 2.0 bearer tokens, signed webhooks, XML for every submission. | REST API and webhooks are common. | ## Frequently asked questions ### Is the CodeB eForms Server the same as the Aloaha eForms Server? Yes. The Aloaha eForms Server was renamed CodeB eForms Server in October 2026. It is still made by Aloaha Limited in Malta. ### What is CodeB eForms Server? A web-based platform to design, publish and process electronic forms. One design is published as fillable PDF, responsive HTML and static HTML; submissions are delivered as sealed PDF plus XML by e-mail. ### Do form users need Adobe Reader or an app? No. The responsive HTML version works in any current browser on phones, tablets and desktops. The dynamic PDF version is available for people who prefer Adobe Reader. ### Can forms be signed? Yes. Handwritten signatures are captured with finger or mouse and sealed by the server. Forms that require sign-in can be signed with the signer's own key at the CodeB server, others receive your organisation's seal, both as PAdES up to B-LTA. Fields named esignature become PDF signature fields for X.509 certificates and smart cards. ### Where are submitted data stored? By default nowhere: the submission is delivered by e-mail as sealed PDF and XML and then removed. An optional encrypted archive can keep password-protected copies. ### Can I run it in my own data centre? Yes. The server runs on Windows Server with IIS and the .NET Framework 4.7.2. Aloaha can also host it for you. ### How is the eForms Server licensed? Is there a trial? You can use the eForms Server hosted by Aloaha or rent a server for installation in your own data centre; rented in-house servers receive free updates, and integration help and online training are free. A free 30-day trial with three example forms is available. For prices, write to info@aloaha.com. ### Can I send e-invoices without my own invoicing software? Yes. Design your invoice template once on the eForms Server and fill it in for each invoice; every submission becomes a compliant ZUGFeRD / XRechnung e-invoice (PDF/A-3 with EN 16931 XML), sent by e-mail. ### Can the eForms Server create e-invoices? Yes. Invoice forms can be converted to ZUGFeRD / Factur-X (EN 16931) on submission: a PDF/A-3 with the embedded invoice XML. ### Is the CodeB eForms Server a form builder? It is a form server: you build forms in its browser-based designer like in a form builder, but every form also exists as fillable PDF, every submission is a sealed PDF plus XML, and you can run the server yourself. ### Does the CodeB eForms Server have an API and webhooks? Yes. A REST API described as OpenAPI 3.1 lists forms and fields, validates, fills and submits forms and creates e-invoices; webhooks send every submission as signed JSON to your system. ## See it with your own forms Try the public sample forms, or ask us for a free online presentation or a free 30-day trial. --- # Feature reference: Every feature, in one place. URL: https://www.form-provider.com/en/features.html This page lists what the eForms Server can do, grouped by the stages of a form: design, publishing, filling in, delivery, signing, e-invoicing, users and operation. ## In short - Design: WYSIWYG editor in the browser with text fields, check boxes, radio buttons, drop-downs, images and signature fields; validation by regular expression. - Publish: dynamic PDF, responsive HTML and static HTML from one design; the server picks the format per device. - Deliver: sealed PDF to the submitter, PDF plus XML to the business owner; attachments become PDF pages or a ZIP file. - Integrate: OpenID Connect sign-in, REST API (OpenAPI 3.1), webhooks, ZUGFeRD / XRechnung, on-premises or hosted. ## Designing forms - WYSIWYG designer in the browser: no installation; works on any workstation with a current browser. - Field types: text fields, multi-line text, check boxes, radio buttons, drop-down lists, buttons, lines, images, plain text and signature fields. - Layout: font, font size, colours, background colour, alignment, maximum length, required fields. - Validation: a regular expression per field, with ready-made rules for e-mail addresses and ID card numbers and custom error messages. - Letterheads and cascaded documents: a form can depend on a letterhead; change the letterhead once and every dependent form follows. - Templates and cloning: start from a template wizard or clone an existing form. - Backup: export a form with all settings and restore it on the same or another server. ## Publishing - Three formats from one design: dynamic PDF (AcroForm, for Adobe Reader), responsive HTML for phones and tablets, and static HTML that keeps the print layout. - Automatic format choice: the server detects the device and delivers the suitable format; links can also request a format explicitly (pdf=1, web=1, static=1). - Release workflow: preview the PDF, release the form, receive an e-mail when rendering is complete. - Multilingual: language variants of forms and of all e-mail texts. ## Filling in and submitting - Any device: phones, tablets, desktop browsers and Adobe Reader. - Attachments: users can add documents before submitting; images become PDF pages, other files are zipped and attached. Forms can require attachments. - Spam protection without CAPTCHA: an invisible check built into the server keeps bots out. Nobody has to click pictures or type distorted letters, and no third-party service such as Google reCAPTCHA sees your visitors. - Remembers your entries: when someone opens the same form again, their earlier entries are filled in from their own browser, separately for every form. Nothing is stored on the server, and one click clears them. - Pre-filling from a verified identity: after sign-in with an Aloaha or CodeB account, for example with the EU Digital Identity Wallet at www.aloaha.com, name and address fields can be filled automatically. - Handwritten signature fields right in the form, see Signatures. ## Delivery and data - Sealed PDF: every submission is rendered as PDF and digitally sealed by the server. - Two e-mails: the submitter receives the sealed PDF; the business owner receives the PDF plus the form data as XML for further processing. Additional recipients can be configured. - Mail templates: subject, body and footer per form group and language, with placeholders such as form ID, document ID, submission ID and link. - No submission database: data are delivered and removed. An optional encrypted archive keeps password-protected PDFs, retrievable only with the submission ID. - Counters and reports: submissions per form and per month, as CSV report. ## Signatures - Handwritten electronic signature with finger, pen or mouse, bound to the document by a SHA-512 server signature. - Optional timestamp from an RFC 3161 timestamp server, such as the Aloaha Timestamping Server. - X.509 signature fields: text fields named esignature become PDF signature fields for certificates and smart cards (advanced and qualified signatures). ## E-invoicing - ZUGFeRD / Factur-X: invoice forms are converted to EN 16931 e-invoices on submission (PDF/A-3 with embedded XML). - ZUGFeRD tools: extract the XML from a ZUGFeRD PDF, embed XML into an existing PDF, or create the PDF from XML with a DOCX template; also as web service. ## Users, groups and sign-in - Roles: administrators, users (form designers) and guests. - Form groups: each group sees and manages its own forms; every form has a business owner and a designer. - Sign-in with Aloaha and CodeB accounts: next to local accounts, the log-in page offers sign-in with www.aloaha.com, phone.codeb.io and phone.aloaha.com (OpenID Connect, authorization code flow with PKCE). The role of the account (administrator, user or guest) is applied unchanged, and the account's server becomes its form group. - Passkeys and EU Digital Identity Wallet: www.aloaha.com already supports sign-in with password, passkey (FIDO2 / WebAuthn) and the upcoming European Digital Identity Wallet (eIDAS 2.0, OpenID4VP, SD-JWT VC). Because the eForms Server signs in through it, these methods work for the form server, too. More on the EU Digital Identity Wallet. - Per-form authentication: a form can require sign-in before it can be filled in. ## Aloaha ID: one sign-in for your applications The sign-in behind the eForms Server is www.aloaha.com, a standard OpenID Connect provider operated by Aloaha. You can use it for your own applications as well: - Standard protocol: OpenID Connect with the authorization code flow and PKCE, signed ID tokens (RS256), userinfo, logout and token revocation. Any OIDC library works; the discovery document is at www.aloaha.com/.well-known/openid-configuration. - Modern sign-in methods: password, passkey (FIDO2 / WebAuthn), e-mail link and the European Digital Identity Wallet (eIDAS 2.0, OpenID4VP, SD-JWT VC), ready before the wallet becomes mandatory to accept. - Roles and groups: the role and groups claims let your application keep administrator, user and guest rights in one place. - Privacy controls: data agreements, consent receipts, an access log and data deletion requests for every user. The same service runs on phone.codeb.io and phone.aloaha.com. To connect your application, write to info@aloaha.com or read the API documentation. ## Integration and operation - Embedding: link to a form or embed it in your website; the URL decides the format. - On-premises or hosted: run it in your own data centre or use a server hosted by Aloaha. - Requirements: Windows Server with IIS (integrated pipeline) and .NET Framework 4.7.2. - Training and support: free online training and integration help; free updates for rented in-house servers. ## Frequently asked questions ### Which field types does the designer support? Text fields, multi-line text, check boxes, radio buttons, drop-down lists, buttons, lines, images, plain text and signature fields. ### How is input validated? Each field can have a regular expression and an error message. Ready-made rules exist for e-mail addresses and ID card numbers. ### What happens to attachments? Images are converted into PDF pages; other files are zipped and attached to the submitted PDF. ### Which sign-in methods are available? Local user accounts and sign-in with an Aloaha or CodeB account through OpenID Connect: www.aloaha.com, phone.codeb.io and phone.aloaha.com. The role of the account (administrator, user or guest) is kept. ### Do the forms use a CAPTCHA? No. The eForms Server has its own invisible bot protection: the browser solves a small computing task in the background while the form is being filled in, and the server also checks timing, a hidden trap field and that each form is sent only once. People see nothing of it, and no third-party CAPTCHA service is involved. ### Can people sign in with the EU Digital Identity Wallet? Yes, through www.aloaha.com. It already accepts the upcoming European Digital Identity Wallet as well as passkeys, and passes the verified sign-in to the eForms Server by OpenID Connect. --- # Online form designer: Create forms in the browser. URL: https://www.form-provider.com/en/form-designer.html The Aloaha online form designer is a WYSIWYG editor: you place fields where they belong on the page and the server produces the PDF and HTML versions. No downloads, no programming. ## In short - No installation: the designer runs in any current browser, on the desktop and with touch on tablets and phones. - Fields: single- and multi-line text, check boxes, radio buttons, drop-downs, images, text, lines, buttons, handwritten and X.509 signature fields. - Rules: every input field can have a regular expression and an error message; required fields are marked. - Result: one release produces the fillable PDF and both HTML versions of the form. ## What you can place - **Input fields**: Single- and multi-line text, check boxes, radio buttons and drop-down lists, each with its own validation rule. - **Content**: Images, plain text and lines to rebuild any paper form. - **Buttons and signatures**: Function buttons, handwritten signature fields and esignature fields for X.509 certificates. ## The designer in pictures The editor shows the page as it will be printed: tools on the left, the page in the middle, the selected field on the right. Double-click a field to set its name, type, rule and colours. Switch on Preview to see the form exactly as people will get it, and on a phone the same editor works with your fingers. Every step is explained in the editor manual. ![The CodeB eForms Server form designer: tools on the left, the form page in the middle, the selected field on the right](https://www.form-provider.com/web-assets/manual/editor-overview.png) ![Field properties dialog: name, type, validation rule, font and colours of a form field](https://www.form-provider.com/web-assets/manual/editor-properties.png) ![Preview of the form page without field outlines, as the released PDF will look](https://www.form-provider.com/web-assets/manual/editor-preview.png) ![The form designer on a phone: the page, the Tools panel and the Field panel](https://www.form-provider.com/web-assets/manual/editor-mobile.png) ## Rules, letterheads and reuse Validation: every field can carry a regular expression and an error message, for example for e-mail addresses or ID card numbers. Letterheads: forms can depend on one or more documents such as a letterhead. Update the letterhead once and every dependent form follows; language-specific letterheads switch the form language automatically. Reuse: clone an existing form to save time, start from templates, and export forms as backup to restore them later or on another server. ## Create your first form 1. Log in and click Create new form. 2. Enter a unique Document ID, your e-mail address as notification address and a short description. 3. Click Create Field to add objects to the page. 4. Select an object and choose its type under Field Properties; set text, values, images and validation. 5. Press Show PDF to preview the fillable PDF. 6. Press Release PDF. The server renders the dynamic PDF and both HTML versions and notifies you by e-mail. ## Who uses the designer Form owners in administration, insurance, property management, hotels, schools and companies use the designer to turn existing paper or PDF forms into online forms. Upload the original as letterhead, place the input fields on top, add validation rules and release it. Because the designer works with points on the PDF page, the released PDF looks exactly like the original, and the responsive HTML version adapts the same fields to small screens. The editor manual explains every tool step by step, and the REST API lets your software read the fields of any released form. ## Frequently asked questions ### Do I need to install anything to design forms? No. The designer runs in the browser. ### Can I reuse an existing form? Yes. Clone it from the form library, or use a letterhead that many forms depend on. ### Can I use my existing PDF or paper form? Yes. Upload the original as a letterhead and place the input fields on top of it; the released PDF keeps the original layout. ### Does the designer work on a tablet or phone? Yes. The editor works with touch: tap to select, drag to move, and use the panels at the bottom on small screens. ### Which formats does a released form have? Every released form is available as dynamic PDF (AcroForm), responsive HTML and static HTML from one link. ## Try the designer Ask for a free 30-day trial, or book a free online presentation. --- # Editor manual: Editor manual: from blank page to released form. URL: https://www.form-provider.com/en/editor-manual.html This manual walks through the form editor of the CodeB eForms Server: where everything is, how to place and arrange fields, how to set their properties and how to release the finished form. The screenshots show the sample form "Meldeschein" (German hotel registration). The editor itself is in English. ## In short - Layout: top bar with page switcher and Release, tools on the left, the page in the middle, the selected field on the right. - Units: positions and sizes are in points (1/72 inch), the PDF unit. - Safety net: restore points before delete, merge and page changes; Go back returns to the last one. - Touch: on phones the tools open as panels from the bottom bar; Select several replaces Ctrl + click. ## Contents 1. The editor at a glance 2. Adding fields 3. Selecting, moving and resizing 4. Field properties 5. Arranging several fields 6. Pages 7. Undo and house style 8. Preview and PDF 9. Releasing the form 10. On a phone or tablet 11. Classic view 12. Questions and answers ## The editor at a glance Open a form from the form library with edit, or create a new one with Create new form. The editor has four areas: - Top bar: the form name and page count, and the actions for the whole form: Form library (back), Show PDF, Download PDF and Release form. - Tools on the left: add fields, work with the selected fields, pages, and undo. - The page in the middle: what you see here is what the form looks like. Every field sits exactly where it will be in the PDF. - Selected field on the right: type, position and size of the field you clicked, and short tips. Hover over any tool to see what it does. On a phone or tablet see below. ![The form editor: tools on the left, the page in the middle, the selected field on the right](https://www.form-provider.com/web-assets/manual/editor-overview.png) ![Top bar of the editor with form name, Form library, Show PDF, Download PDF and Release form](https://www.form-provider.com/web-assets/manual/editor-topbar.png) ## Adding fields Click Add field at the top of the tools. A new field appears in a corner of the page; drag it to its place. Every new field starts as a text element. Choose what it should be in the type list on the right (Selected field): - Text Field: an input box the person fills in. - Plain Text: fixed text such as headings, labels and notes. - Drop Down, Check Box, Radio Button: choices. - Image, Line, Button: pictures, rules and buttons. ### Letterhead Upload letterhead puts a PDF or image behind the page, for example your company letterhead or a scanned paper form to trace. Remove letterhead takes it away again. ![Tools on the left: Add field, letterhead, selected fields, line up, make equal and same look](https://www.form-provider.com/web-assets/manual/editor-tools.png) ## Selecting, moving and resizing - Select: click a field. It gets an orange frame. - Select several: hold Ctrl and click more fields, or drag a rectangle across an empty part of the page. - Move: drag the field. - Resize: drag the small handle in its bottom-right corner. - Exact values: type X, Y, width and height on the right. Values are in points (1/72 inch, the PDF unit). X is measured from the left edge, Y from the bottom edge of the page, as in a PDF. - Delete: Delete Field on the right, Delete in the tools, or right-click the field. The box at the top of the tools always tells you how many fields are selected. ![Two selected fields with an orange frame on the page](https://www.form-provider.com/web-assets/manual/editor-selection.png) ![Selected field panel with type, X, Y, width and height](https://www.form-provider.com/web-assets/manual/editor-inspector.png) ## Field properties Double-click a field, or click Field Properties on the right, to open its properties: - Name: the field name in the PDF and in the XML data you receive. Use short, unique names such as Surname. - Group ID: fields with the same group belong together, for example the radio buttons of one question. - Description: the label shown to the person filling in, also used in messages and in the HTML version. - Field is Required and Validation: make the field mandatory and check the input, for example an e-mail address, a date or a postcode. - Text: preset text, or the text of a Plain Text element. Toggle HTML switches to formatted text. - Background, Font, size and colour, Bold, Italics, Block Justify. - Multiline: allows several lines of input. Text as Comb with Max. Characters spreads the characters evenly in boxes, as on paper forms. Click OK to apply, Cancel to discard. Images have their own small dialog to upload the picture; buttons and lines have one for label, colours and action. ![Form Properties dialog with name, group ID, description, required, validation, text, background, font and comb settings](https://www.form-provider.com/web-assets/manual/editor-properties.png) ## Arranging several fields Select two or more fields, then use the tools on the left: - Selected fields: Copy and Paste (tip: right-click the page and choose Paste to put the copies exactly there), Duplicate (copy next to the original), Delete, Merge into one. - Line up: align the left, centre, right, top or bottom edges. - Make equal: same width, same height, even gaps across or down. - Same look: same font, same colours, same group, or mark the fields as a table. ### Combining commands Some commands have a small box next to them. Tick it, and that command also runs together with the next command you click. Example: tick Same width, then click Left: the fields get the same width and are lined up on the left in one step. ## Pages A form can have several pages. To move between them, use the page switcher in the top bar, next to the form name: the arrows go to the previous and the next page, the list jumps straight to a page (for example Page 2 of 3). On a phone it shows only the arrows and the number. Under Pages in the tools: - Page and Orientation: jump to a page, switch between portrait and landscape. - Previous and Next: the same as the arrows in the top bar. - Add page, Copy page (with all fields), Delete page. The line above the page shows where you are, for example Page 1 of 2 · Portrait · 595 × 842 pt (A4). ![Pages, and Undo and checks in the tools](https://www.form-provider.com/web-assets/manual/editor-tools-pages.png) ## Undo and house style - Save restore point: remembers the current state of the form. - Go back: returns to the last restore point. Undo go back reverses that. - Apply house style: sets left margin, width, height, font and colours of all fields from the style rules of your server, so every form looks the same. Delete, merge, page changes and the house style save a restore point automatically before they change anything. ## Preview and PDF While you work, the fields have light outlines so you can find them. Switch on Preview above the page to hide all outlines and handles: the page then looks like the released form. Show PDF creates the PDF and opens it in a new tab. Download PDF saves it. ![The page in Preview: no outlines, it looks like the final PDF](https://www.form-provider.com/web-assets/manual/editor-preview.png) ## Releasing the form A form is public only after it was released. Click Release form in the top bar: - Form Designer eMail: your address; you get notices about the form. - Business Owner eMail: receives every submission as a sealed PDF with the data as XML. - Options for attachments (required, images only, uploader on the last page), the submit button and a permanent redirect. - Require sign-in with : visitors sign in with that server first; the form is pre-filled from their account. - Sign the PDF when it is submitted: every submitted PDF is signed, with the personal key of the signed-in person when the form requires sign-in, otherwise with the seal of the organisation (Signatures). Click OK. The server then creates the PDF, the responsive HTML and the static HTML of the form. Release the form again after every change; until then visitors see the previous version. ![Release Form dialog with designer and business owner e-mail and options](https://www.form-provider.com/web-assets/manual/editor-release.png) ## On a phone or tablet The editor also works with your fingers, on tablets and phones. On a phone the tools and the selected field open as panels from the bar at the bottom: Tools, Field (the number shows how many fields are selected), Select several and Preview. - Select: tap a field. Tap it again to deselect it. - Move and resize: drag a selected field with your finger, or drag the orange dot in its corner to resize it. Swiping anywhere else scrolls the page, so you never move a field by accident. - Exact position: under Field, the arrows move the field by 1 pt or 10 pt; width and height are set in the boxes above them. - Several fields: turn on Select several, then tap the fields. Turn it off again when you are done. - Properties: double-tap a field, or tap Field Properties under Field. - Zoom: the page is shown at its real size; pinch to zoom out and see the whole page. ![The editor on a phone: the page, the Tools panel and the Field panel with the arrows to move a field](https://www.form-provider.com/web-assets/manual/editor-mobile.png) ## Classic view The previous layout of the editor is still there: click Classic view at the right of the top bar. Switch to the new editor (bottom right) brings you back. Both work on the same form and give exactly the same result; the browser remembers your choice. ## Questions and answers ### Does the editor show the form exactly as it will look? Yes. Every field is shown at its real position and size in points, with its font and colours. Switch on Preview to hide the editing outlines; Show PDF displays the generated PDF. ### How do I select several fields? Hold Ctrl and click the fields, or drag a rectangle across an empty part of the page. The box at the top of the tools shows how many fields are selected. ### Why are some tools grey? They work on selected fields. Select one or more fields on the page and they become active. ### Why does my change not appear in the public form? Visitors see the released version. Click Release form again after changes. ### Can I undo a mistake? Yes. Go back returns to the last restore point; delete, merge and page changes save one automatically. Save restore point creates one whenever you like. ### Can I use the editor on a phone or tablet? Yes. Tap a field to select it, then drag it with your finger to move it. On a phone the tools and field settings open from the bar at the bottom; Select several replaces Ctrl + click and the arrows under Field move a field exactly. ### Where is the old editor? Click Classic view in the top bar. Switch to the new editor brings you back. ## Try it with your own forms Ask for a free online presentation or a free 30-day trial. --- # Mobile-ready forms: Paperless on every screen. URL: https://www.form-provider.com/en/responsive-forms.html Paper workflows cost time and produce errors. CodeB eForms are filled in, signed and sent directly on the device at hand, and every form is available as responsive HTML and as fillable PDF. ## In short - Three formats, one link: responsive HTML (phones, tablets), static HTML (desktop, print layout) and dynamic PDF (Adobe Reader). - Automatic: the server detects the device; web=1, static=1 or pdf=1 in the link force a format. - No app: people fill in, sign and send forms in the browser they already have. ## Why organisations switch - **Collect data reliably**: Validated input instead of illegible handwriting; data arrive as XML. - **Simplify compliance**: Sealed PDFs, signatures and timestamps document every submission. - **Keep one look**: Letterheads and cascading forms keep your corporate design consistent. ## Three formats, one link The server chooses automatically. Add a parameter to the form link to ask for a specific format. | Format | Best for | Link parameter | |---|---|---| | Responsive HTML | Phones and tablets | web=1 | | Static HTML | Desktop browsers, print layout | static=1 | | Dynamic PDF | Adobe Reader, offline filling | pdf=1 | ## How the format is chosen A form link opens pdfforms.aspx?fid=
. The server looks at the device: phones and tablets get the responsive HTML version, desktop browsers the static HTML version that keeps the print layout, and Adobe Reader the dynamic PDF. Add &web=1, &static=1 or &pdf=1 to force one format, for example in a QR code on a poster that should always open the mobile version. All three versions submit to the same place: the result is the same sealed PDF with the same XML data, whichever version the person used. Values the person typed can be remembered by the browser for a later visit, and a prefilled link opens the form with values already filled in. ## Frequently asked questions ### Do users need an app? No. Any current browser is enough; Adobe Reader is optional for the PDF version. ### Which Adobe Reader version does the PDF version need? The dynamic PDF version needs Adobe Reader XI or later. The responsive and static HTML versions need only a current browser. ### How do I put a form on my website? Link to the form or embed it. The link decides the format, or the server chooses automatically. ### Do all three formats produce the same result? Yes. Responsive HTML, static HTML and the PDF all submit the same fields; the result is the same sealed PDF with XML data. ### Can I send someone a form that is already filled in? Yes. The REST API creates prefilled links that open the web form with given values, valid for 7 days by default. --- # Signatures: Sign forms on any device. URL: https://www.form-provider.com/en/signatures.html The eForms Server supports two kinds of signatures: handwritten electronic signatures drawn right in the form, and digital X.509 signatures applied in Adobe Reader with a certificate or smart card. ## In short - Handwritten: signed with finger, pen or mouse in the form; the server binds it to the document with a SHA-512 signature. - Per form: "Sign the PDF when it is submitted" in the release dialog; forms with sign-in are signed with the user's own key at the CodeB server, all others get the seal of the organisation. - Long-term: signatures from the CodeB signing service reach PAdES B-LTA: signature timestamp, validation data (certificates and OCSP responses) and an archive document timestamp. - X.509: text fields named esignature become PDF signature fields for certificates and smart cards (advanced and qualified signatures). ## Handwritten electronic signatures Signature fields can be signed with a finger or pen on phones and tablets, or with the mouse on a desktop. Your devices become a signature pad without buying hardware or installing an app. - The signature is bound to exactly one document by a SHA-512 digital signature of the server. - The server signature can carry a timestamp from an RFC 3161 time stamping authority, such as the Aloaha Timestamping Server. - All communication between the device and the server is encrypted with TLS. Typical uses: signatures in a branch or at the counter, field staff collecting signatures on site, and confirmations of visits or deliveries. ## Digital X.509 signatures Name a text field esignature in the designer and it becomes a PDF signature field. After submission the user opens the confirmed PDF in Adobe Reader, clicks the field and signs with a certificate or smart card. A submit button sends the signed PDF to the business owner of the form. ## Signature levels under eIDAS The EU regulation eIDAS distinguishes three levels of electronic signature. | Level | What it is | With the eForms Server | |---|---|---| | Simple (SES) | Any electronic sign of intent, for example a drawn signature. | Handwritten signature, sealed and timestamped by the server. | | Advanced (AES) | Uniquely linked to the signer, detects later changes. | Signature with the personal key of the signed-in person at a CodeB server (forms with sign-in), or an X.509 signature field with a personal certificate. | | Qualified (QES) | Advanced signature with a qualified certificate on a secure device. | X.509 signature field with a qualified smart card, for example with the Aloaha PDF Signator. | ## What the server records When a form with a handwritten signature is submitted, the server renders the complete form including the signature image as PDF and seals it with its own digital signature (SHA-512). Any later change to the PDF breaks the seal, which PDF readers such as Adobe Reader show. With an RFC 3161 timestamp server configured, the seal also proves when the document was signed. The submitter and the form owner receive the same sealed PDF. For a stronger level, forms can require sign-in with a verified identity, for example the EU Digital Identity Wallet, and the PDF records how the person signed in. ## Seal or sign each submission Whether the PDF of a submission is signed is set per form: tick Sign the PDF when it is submitted when you release the form. The server then signs every submitted PDF in this order: - Forms that require sign-in with a CodeB server (for example phone.codeb.io) are signed with the personal key of the signed-in person at that same server. The server uses the person's sign-in for this, so nobody has to install software or enter a certificate password. - All other forms receive the seal of the organisation: from the CodeB signing service with a dedicated account, or from a certificate on the form server itself. - If the personal signature is not possible, for example because the person's key needs a PIN, the PDF receives the seal of the organisation instead, so no submission is lost. Signatures from the CodeB signing service are advanced electronic signatures in PAdES format (not qualified) and are invisible on the page; PDF readers list them in the signature panel. By default they reach level PAdES B-LTA: - B-T: an RFC 3161 timestamp proves when the PDF was signed. - B-LT: the certificates and OCSP responses are embedded, so the signature can be checked later without the original servers. - B-LTA: an archive document timestamp protects the signature and the validation data. The signing service reports the level it delivered. A PDF below the lowest level you accept (a setting) is sealed by the organisation instead. Forms with a handwritten signature are always sealed. ## Frequently asked questions ### Is a handwritten signature in a web form legally valid? It is a simple electronic signature under eIDAS. The eForms Server binds it to the document with a server signature and an optional timestamp, so later changes are detected. ### Can forms be signed with a smart card? Yes. Fields named esignature become PDF signature fields that can be signed in Adobe Reader with X.509 certificates and smart cards. ### What is the difference between a sealed PDF and a signed PDF? The seal is the server's digital signature over the submitted form: it proves the document has not changed since submission. A personal X.509 signature is made by the signer with their own certificate or smart card in the esignature field. ### Do I need a signature pad? No. Phones and tablets work with a finger or pen, desktops with the mouse; no hardware or app is needed. ### Can the person who fills in the form sign it with their own key? Yes, if the form requires sign-in with a CodeB server and is set to be signed on submission. The submitted PDF is then signed with the personal key of the signed-in person at the server that signed them in, as an advanced electronic signature (PAdES, not qualified). If that is not possible, the PDF gets the seal of the organisation. ### Can I choose which forms are signed? Yes. Tick or clear "Sign the PDF when it is submitted" when you release the form. Forms with a handwritten signature are always sealed. ### Can a signed PDF still be verified in ten years? A PAdES B-LTA signature carries its own validation data and an archive timestamp, so it can be checked without the servers that issued the certificates. To keep it verifiable beyond the lifetime of the timestamp certificate, a new archive timestamp has to be added before that certificate expires. ### What happens if the timestamp service is down? The signer's own signature is then made without a timestamp (level B-B), as long as the lowest accepted level allows it; otherwise the PDF receives the seal of the organisation. The level reached is written to the server's event log. --- # EUDI Wallet: The EU Digital Identity Wallet, ready for your forms today. URL: https://www.form-provider.com/en/eudi-wallet.html The European Digital Identity Wallet (EUDI Wallet) lets every person in the EU prove who they are and share verified data from their phone. With www.aloaha.com, the CodeB eForms Server already accepts it: people sign in with the wallet and their forms are pre-filled with verified data. Every EU member state must offer a wallet by the end of 2026, and banks, telecom operators, utilities, health services and large online platforms must accept it by the end of 2027. You can be ready now. ## In short - Today: forms on the CodeB eForms Server accept the EU Digital Identity Wallet through the sign-in service www.aloaha.com. - Standards: OpenID4VP with DCQL, SD-JWT VC and ISO mdoc credentials, HAIP profile of the EU Architecture and Reference Framework. - Deadlines: wallets in every EU member state by the end of 2026; acceptance by regulated private services by the end of 2027 (eIDAS 2.0, Regulation (EU) 2024/1183). - Own app: CodeB Wallet for Android holds PID, driving licence and membership cards, shares them with OpenID4VP or ISO/IEC 18013-5, checks IDs, reads passport chips and signs PDFs (AdES; QES with a qualified card such as the Maltese eID, in testing). Closed beta; not an official government wallet, not certified. ## What is the EUDI Wallet? The European Digital Identity Wallet is an app that every EU member state provides to its citizens and residents, free of charge for private use. It holds the person identification data (PID: name, date of birth, nationality, address) issued by the state, and can also hold other credentials such as a driving licence, diplomas, professional qualifications or proof of age. The legal basis is eIDAS 2.0, Regulation (EU) 2024/1183, which amends the eIDAS Regulation (EU) No 910/2014 and entered into force on 20 May 2024. The technical rules come from the EU Architecture and Reference Framework (ARF) and its implementing acts. - The person decides: the wallet shows which data a service asks for, and nothing is shared without consent. - Only what is needed: with selective disclosure a form can ask for name and address without seeing anything else. - Verified at the source: the data are signed by the issuing authority, so they cannot be typed wrongly or faked. - Accepted across the EU: a wallet from one member state works with services in all others. ## Key dates The timetable of eIDAS 2.0 for wallets and the services that accept them. | When | What happens | |---|---| | 20 May 2024 | eIDAS 2.0, Regulation (EU) 2024/1183, enters into force. | | End of 2026 | Every EU member state must offer at least one certified EUDI Wallet to its citizens and residents, including free qualified electronic signatures for private use. | | End of 2027 | Private services that must identify users strongly by law, such as banks, payment services, telecom operators, energy suppliers, transport, health services and education, and very large online platforms, must accept the wallet when the user wants to use it. | ## Why it matters for forms Most forms start with the same questions: who are you, when were you born, where do you live? Today people type these data again and again, make mistakes, and the organisation behind the form has no proof that they are true. The wallet changes that. - Faster forms: one confirmation in the wallet fills name, date of birth and address. - Fewer errors and less fraud: the data come signed from the issuing authority instead of being typed in. - Data minimisation under the GDPR: the form receives only the data it asks for, and the person sees and approves it. - No accounts to manage: people do not need yet another password for your forms. - Ready before the deadline: if you must accept the wallet from the end of 2027, your forms already do. ## How Aloaha supports the wallet today Two parts work together: the sign-in service www.aloaha.com and the eForms Server. - **www.aloaha.com accepts the wallet**: The Aloaha sign-in service verifies wallet presentations with OpenID for Verifiable Presentations (OpenID4VP) and DCQL queries, for SD-JWT VC and ISO mdoc credentials, following the High Assurance Interoperability Profile (HAIP) of the ARF. - **One OpenID Connect sign-in**: Applications connect to www.aloaha.com with standard OpenID Connect. They receive the verified data like any other sign-in, without wallet code of their own. - **Forms that require sign-in**: Put a form into the group of the sign-in server and tick “Require sign-in”. Every visitor signs in first, with the wallet, a passkey or a password. - **Pre-filled with verified data**: Name, date of birth and address that the person shares from the wallet go straight into the matching form fields. The submitted PDF records how the person signed in. - **Passkeys and passwords too**: People without a wallet yet sign in with a passkey (FIDO2 / WebAuthn) or a password. You do not need two systems. - **Hosted in the EU**: Aloaha Limited is based in Malta. The eForms Server can run in your own data centre, so form data never leave your infrastructure. ## CodeB Wallet: our own EUDI Wallet app for Android Besides accepting the state wallets, Aloaha builds its own wallet app: CodeB Wallet for Android, designed for eIDAS 2.0 (Regulation (EU) 2024/1183) and the EU Architecture and Reference Framework. It keeps your digital ID, driving licence and membership cards on the phone, shows them in person or online, checks other people's IDs and signs PDFs. CodeB Wallet is in a closed beta on Google Play for invited testers; the public release and an iPhone version are announced as coming soon. The app speaks English, German and Maltese. It is not an official government wallet and it is not certified. Your browser cannot play this video. Download the teaser (MP4, 2 MB) CodeB Wallet in 32 seconds: add a card, share only what is needed, sign a PDF, check an ID or just the age. The video has no sound. Also on YouTube: English, German. - Documents: person identification data (PID, including a German PID), the mobile driving licence (SD-JWT VC and ISO/IEC 18013-5 mdoc) and a CodeB membership card, received with OpenID4VCI from the CodeB issuer (phone.codeb.io) or by scanning the QR code of another issuer. The EU reference issuers can be chosen as well; issuers are checked against ETSI trusted lists. Coming soon: a Photo ID (ISO/IEC TS 23220-4), optionally with the chip data of the passport as ICAO Digital Travel Credential, only with the holder's consent. - Sign PDFs with the CodeB signing service: advanced electronic signatures (AdES) as PAdES B-T with trusted timestamp, made with the same Aloaha PDF technology as the eForms Server (Signatures). The document stays on the phone and every signature is confirmed. These are not qualified signatures. A PDF someone else sends can be signed by scanning the QR code of phone.codeb.io/sign-request. - Sign with your own signature card (in testing): the phone is the NFC card reader, no computer or USB reader is needed. The Maltese eID card and Maltese residence cards with a signature certificate create a qualified electronic signature (QES), because the card holds a qualified certificate; the CAN opens the encrypted PACE connection, the signature PIN goes only to the card, and the key never leaves the chip. Also supported: D-Trust Card 5.1 (QES) and 5.4 (qualified seal), the German health professional card HBA G2.1 (QES) and the health insurance card eGK G2.1 (advanced signature). The app shows whether the card certificate states a qualified signature; according to myeuid.app, QES was fully tested with real Maltese eID and D-Trust cards. The qualified status comes from the card, not from the app: CodeB Wallet itself is not certified. - Read passports and ID cards (in testing): the app reads the chip of ePassports and chip ID cards according to ICAO Doc 9303 (name, date of birth, nationality, document number, expiry date, photo) with the CAN or the MRZ scanned by the camera, checks the issuing state's signature against the CSCA master lists and detects cloned chips. For a PID, the CodeB PID provider can read the chip through the phone over an end-to-end protected channel (PACE, Chip Authentication, Secure Messaging); the phone only relays the messages, and the genuine app is checked with Android Key Attestation and Play Integrity. - Free CodeB account (in testing): created in the app by scanning the chip of a passport or ID card and confirming an e-mail code. It allows five signed PDFs per day and the test PID and Photo ID. It is a document-checked guest account, not an official identity and not a qualified signature; CAN, MRZ and raw chip data are not kept. - Show and check IDs: in person with ISO/IEC 18013-5, started by QR code or NFC tap, data over Bluetooth Low Energy, also offline; online with OpenID for Verifiable Presentations (OpenID4VP), the standard www.aloaha.com verifies for your forms. Selective disclosure shares only what is needed, for example "over 18" instead of the date of birth. In verifier mode the same app checks another person's ID, including revocation, gives a clear verdict and deletes the data when the result is closed. - Privacy and security: keys in the phone's secure hardware, PIN and optional biometrics, every share and signature confirmed. Documents and history stay on the phone, with no CodeB cloud and no ads, tracking or analytics. Status checks and renewal run automatically where the issuer supports them, and a local history shows who saw a document. The app works with TalkBack, large text and reduced animations. - White label: issuers, banks, public bodies, associations and companies can offer the wallet under their own name, logo, colours and store listing, with their own issuers and services (also not certified). More on myeuid.app: manual, signing with the Maltese eID, D-Trust cards, German health cards, free account and changelog. Testers and white-label enquiries: info@aloaha.com. ## CodeB Wallet at a glance What the app does, the standards behind it and the status reported on myeuid.app (checked 16 October 2026). The whole app is in a closed beta. | Function | Standards | Status | |---|---|---| | Digital ID (PID), mobile driving licence, membership card | OpenID4VCI, SD-JWT VC, ISO mdoc, ETSI trusted lists | Available to testers | | Photo ID with Digital Travel Credential | ISO/IEC TS 23220-4, ICAO DTC type 1 | Coming soon | | Show an ID in person | ISO/IEC 18013-5 (QR, NFC, Bluetooth LE), offline | Available to testers | | Show an ID online | OpenID4VP, selective disclosure | Available to testers | | Check another person's ID or age | ISO/IEC 18013-5 reader, revocation check | Available to testers; back-to-back check in testing | | Read passports and ID cards | ICAO Doc 9303 (PACE, BAC, chip, active and passive authentication) | In testing | | PDF signature with the CodeB signing service | PAdES B-T (ETSI EN 319 142), advanced electronic signature | In testing | | PDF signature with a signature card | NFC, ISO/IEC 7816-4/-8, PACE (BSI TR-03110), ETSI EN 319 412-5; QES with a qualified card such as the Maltese eID | In testing; QES tested with real Maltese eID and D-Trust cards | | Identity proofing at the CodeB PID provider | ETSI TS 119 461 v2.1.1 (designed to follow, not certified) | In testing | | Certification | - | Not certified, not an official government wallet | ## How it works on a form 1. Publish the form. In the designer, put the form into the group of the sign-in server (for example www.aloaha.com) and tick Require sign-in when you release it. 2. Open the link. The visitor opens the form and is sent to www.aloaha.com. 3. Confirm in the wallet. The visitor chooses the EU Digital Identity Wallet, scans the QR code or confirms on the same phone, and approves the data the form asks for. 4. Check the pre-filled form. Back on the form, name, date of birth and address are already filled in. The visitor completes the rest and signs. 5. Submit. The server seals the PDF and delivers it with the XML data by e-mail, as with every eForms submission. ## Typical uses - Public administration: applications and registrations that need a verified identity. - Banks, insurers and utilities: customer onboarding and changes of address, with strong identification as required by law. - Hotels and rentals: guest registration with verified name, date of birth and address, for example the German Meldeschein. - Health and care: consent forms where it must be clear who signed. - Education: enrolment with verified identity and, later, diplomas from the wallet. ## Frequently asked questions ### What is the EU Digital Identity Wallet? An app provided by each EU member state under eIDAS 2.0, Regulation (EU) 2024/1183. It holds the person identification data issued by the state and other credentials, and lets the holder share selected data with online services, with their consent. ### When does the EUDI Wallet become available? Every EU member state must offer at least one certified wallet by the end of 2026. Some countries started earlier with pilots; Germany has announced its state wallet for the start of 2027. ### Who must accept the EUDI Wallet, and from when? Public bodies that offer online identification, and from the end of 2027 private services that must identify users strongly by law, such as banks, telecom operators, energy suppliers, transport and health services, as well as very large online platforms, when the user wants to use the wallet. ### Does the CodeB eForms Server support the EUDI Wallet? Yes. The eForms Server signs people in through www.aloaha.com, which accepts the EU Digital Identity Wallet. Forms can require that sign-in and are then pre-filled with the verified data the person shares. ### Which wallet standards does www.aloaha.com support? OpenID for Verifiable Presentations (OpenID4VP) with DCQL queries, SD-JWT VC and ISO mdoc credentials, following the High Assurance Interoperability Profile and the EU Architecture and Reference Framework. Applications connect with standard OpenID Connect. ### Which data does a form receive from the wallet? Only the data the form asks for and the person approves in the wallet, typically name, date of birth and address. Nothing is shared without consent. ### Can people without a wallet still fill in the form? Yes. They sign in at www.aloaha.com with a passkey or a password instead, or the form is published without required sign-in. ### Is the EUDI Wallet the same as a qualified electronic signature? No, but it includes one: wallet holders can create qualified electronic signatures free of charge for private use. The eForms Server also supports X.509 signature fields for certificates and smart cards. ### Does Aloaha have its own EUDI Wallet app? Yes. CodeB Wallet for Android (myeuid.app) holds a digital ID (PID), the mobile driving licence and a membership card, presents them with OpenID4VP or ISO/IEC 18013-5, checks other IDs, reads the chip of passports and ID cards and signs PDFs. It is in a closed beta on Google Play for invited testers, available in English, German and Maltese, and is neither an official government wallet nor certified. ### Can CodeB Wallet create a qualified electronic signature (QES)? Yes, with a qualified signature card, in testing: the Maltese eID card (and Maltese residence cards with a signature certificate), D-Trust Card 5.1 and the German HBA G2.1 create a QES over NFC, because the card holds a qualified certificate and the key never leaves the chip. The app shows whether the card certificate is qualified. Signatures from the CodeB signing service are advanced signatures (AdES, PAdES B-T), not QES. CodeB Wallet itself is not certified. ### Can CodeB Wallet read passports and ID cards? Yes, in testing. It reads the chip of ePassports and chip ID cards according to ICAO Doc 9303 with the CAN or the machine-readable zone, checks the issuing state's signature against the CSCA master lists and detects cloned chips. Older cards without a chip cannot be read. ### Is CodeB Wallet available for iPhone? Not yet. CodeB Wallet runs on Android with NFC; an iPhone version is announced on myeuid.app as coming soon. ### Can organisations offer CodeB Wallet under their own brand? Yes. Aloaha offers CodeB Wallet as a white-label app with your own name, logo, colours, store listing, issuers and services. The white-label wallet is not certified either. Contact info@aloaha.com. ## Get your forms ready for the wallet Ask for a free online presentation or the connection of your own application to www.aloaha.com. --- # E-invoicing: Invoice forms that become e-invoices. URL: https://www.form-provider.com/en/zugferd.html With the eForms Server an invoice form can be filled in on any device and is converted into a ZUGFeRD / Factur-X e-invoice on submission: a PDF/A-3 that people can read, with embedded XML that software can process. ## In short - Format: ZUGFeRD / Factur-X is a PDF/A-3 with the invoice data embedded as XML according to EN 16931. - XRechnung: the embedded CII XML carries the XRechnung 3.0 identifier and the buyer reference (Leitweg-ID). - How: fill in an invoice form in the browser or send JSON to POST /api/v1/einvoices; the e-invoice is created on submission. ## E-invoices without invoicing software Many small companies, associations and freelancers write only a few invoices a month and do not need their own invoicing software, yet their customers and public-sector buyers increasingly require e-invoices. With the eForms Server you design your invoice template once in the browser, with your company details, letterhead and items, and then fill it in for each invoice. On submission the server creates a compliant e-invoice: a ZUGFeRD / Factur-X PDF/A-3 with embedded EN 16931 XML in XRechnung 3.0 format, delivered by e-mail to you and your customer. - No installation: works in the browser on PC, tablet and phone. - Your own layout: letterhead, logo and fields as you want them; the XML is created from the field names. - Public-sector ready: buyer reference (Leitweg-ID), due date, IBAN and VAT categories including 0 % (exempt, reverse charge, export). ## ZUGFeRD in short ZUGFeRD is the hybrid e-invoice format of the German Forum on Electronic Invoicing (FeRD). Since ZUGFeRD 2.1 it is technically identical to the French Factur-X 1.0 and meets the European standard EN 16931. The structured invoice data are embedded as XML in a PDF/A-3 file, so the invoice can be read by people and processed fully automatically by the recipient. ## What the eForms Server does with ZUGFeRD - **Create on submission**: Invoice data from the form become a ZUGFeRD / Factur-X PDF/A-3 with embedded XML. - **XRechnung 3.0**: The embedded CII XML carries the XRechnung 3.0 identifier, including buyer reference (Leitweg-ID), due date, delivery date and IBAN when the form asks for them. - **Extract and embed**: Read the XML from a ZUGFeRD PDF, or embed XML into an existing PDF. - **PDF from XML**: Render a readable PDF/A-3 from invoice XML with a DOCX template; also as web service. ## Try it: the ZUGFeRD test invoice Fill in a test invoice on this server and receive a ZUGFeRD / XRechnung e-invoice by e-mail: a PDF/A-3 with embedded EN 16931 XML. Use test data only. ## Need an SDK? For your own applications in .NET, COM or on the command line, Aloaha offers the ZUGFeRD Pro SDK. ## Frequently asked questions ### Is ZUGFeRD the same as Factur-X? Yes, technically: ZUGFeRD 2.1 and Factur-X 1.0 are identical, and both follow EN 16931. ### Which standard do the generated invoices follow? EN 16931 (and CEN/TR 16931-4), as PDF/A-3 with embedded XML. ### Are the invoices valid XRechnung? Yes. The XML is written in CII syntax with the XRechnung 3.0 identifier. Test invoices from the form server pass the PDF/A-3b, EN 16931 and XRechnung checks of the Mustang validator. For German public-sector buyers, enter the Leitweg-ID as buyer reference. ### Do I need invoicing software to send e-invoices? No. Design an invoice form once, fill it in for every invoice, and the server sends a ZUGFeRD / XRechnung e-invoice on submission. ### Can my software create e-invoices automatically? Yes. POST /api/v1/einvoices takes the invoice as JSON and returns the e-invoice PDF/A-3; see the e-invoice API page. --- # API: REST API: forms and e-invoices from your own software. URL: https://www.form-provider.com/en/api.html Every form on the server can be used from other applications: list forms, read their fields, check data, get a filled PDF, submit, or create a ZUGFeRD / XRechnung e-invoice from structured data. The API is described as OpenAPI 3.1 and protected with bearer tokens of your OpenID Connect servers. A submission through the API is processed exactly like one from the web form: sealed PDF, optional server signature, e-mails, e-invoice. ## In short - Standard: REST with JSON, described as OpenAPI 3.1 at /api/v1/openapi; errors as RFC 9457 problem details. - Security: OAuth 2.0 bearer tokens of your OpenID Connect servers; roles from the token; rate-limit headers on every answer. - Endpoints: forms, fields, JSON Schema, validate, fill, submit, e-invoices, prefilled links, webhooks and usage. ## Contents 1. At a glance 2. Authentication 3. Getting a bearer token 4. Endpoints 5. Reading forms and fields 6. Filling and submitting 7. E-invoices (ZUGFeRD / XRechnung) 8. Webhooks 9. Prefilled links 10. Usage and rate limits 11. Errors and limits 12. What the API covers 13. Questions and answers ## At a glance - Base URL: https:///api/v1 (on servers without extensionless URLs: /api.ashx/v1). - Description: OpenAPI 3.1 at /api/v1/openapi on every server, and as a download. Import it into Postman, Swagger UI or a code generator. - Format: JSON in and out (UTF-8). PDFs come as Base64 in the JSON answer, or as the file itself with Accept: application/pdf. - Errors: RFC 9457 problem details (application/problem+json). ## Authentication Every call except /, /health, /openapi and /field-types needs an access token of one of the OpenID Connect servers configured on the form server (by default phone.codeb.io, www.aloaha.com and phone.aloaha.com): Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6… - JWT tokens are checked locally: RS256 signature against the server's published keys, issuer, expiry and audience. The audience is the form server's client ID; an administrator can allow further client IDs (settings page, REST API). - Opaque tokens are checked by token introspection at the issuing server. If several servers are configured, name it in the header X-OIDC-Issuer: phone.codeb.io. - Roles come from the token's role claim, like the sign-in to the designer: admin and user see the forms of their group (the sign-in server's host name), guest only released forms. Submitting needs user or admin, unless the administrator allows guests. - GET /api/v1/me shows which user, role and group a token stands for. ## Getting a bearer token The API accepts the access tokens the OpenID Connect servers issue at sign-in (RS256 JWTs, valid for one hour). Your application gets one with the standard authorization code flow with PKCE; any OAuth 2.0 / OpenID Connect library can do this. Below, phone.codeb.io stands for the sign-in server you use. ### 1. Register your application once - At the sign-in server, register your application as an OIDC client (an administrator of the CodeB server does this on /oidc-clients.html, or ask us at info@aloaha.com). You choose a client ID (e.g. my-app) and the redirect URI the sign-in returns to (e.g. http://localhost:8765/callback for a script). The redirect URI must match byte for byte. With a client secret the client is confidential, without one it is a public client and uses PKCE only. - On the form server, an administrator allows the client ID: Settings → REST API → Other applications allowed. Tokens for the form server's own client ID are accepted anyway. ### 2. Sign in and get the code Create a PKCE pair and open the authorization URL in a browser. The user signs in (password, passkey or EU Digital Identity Wallet), and the browser returns to your redirect URI with ?code=…. VERIFIER=$(openssl rand -base64 48 | tr -d '=+/' | cut -c1-64) CHALLENGE=$(printf '%s' "$VERIFIER" | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '=') # open this URL in the browser (one line) https://phone.codeb.io/oauth2/v1/authorize?response_type=code&client_id=my-app &redirect_uri=http%3A%2F%2Flocalhost%3A8765%2Fcallback&scope=openid%20profile%20email &state=xyz&nonce=abc&code_challenge=$CHALLENGE&code_challenge_method=S256 Even if nothing listens on the redirect URI, the code is in the browser's address bar. It is valid for a few minutes and only once. ### 3. Exchange the code for tokens curl -X POST https://phone.codeb.io/oauth2/v1/token \ -d grant_type=authorization_code -d client_id=my-app \ -d redirect_uri=http://localhost:8765/callback \ -d code=$CODE -d code_verifier=$VERIFIER # confidential client: add -d client_secret=$SECRET { "access_token": "eyJhbGciOiJSUzI1NiIs…", "token_type": "Bearer", "expires_in": 3600, "id_token": "eyJ…", "refresh_token": "…" } ### 4. Call the API, refresh when needed curl -H "Authorization: Bearer $ACCESS_TOKEN" https://forms.example.com/api/v1/me # after one hour: new tokens with the refresh token (it rotates on every use) curl -X POST https://phone.codeb.io/oauth2/v1/token \ -d grant_type=refresh_token -d client_id=my-app -d refresh_token=$REFRESH_TOKEN The token acts for the user who signed in: their role decides which forms the API shows (see above). For a background job, sign in once with a dedicated account and keep the token fresh with the refresh token. ### The whole flow as a script Python 3, standard library only: opens the browser, receives the code on localhost and prints the access token. import base64, hashlib, http.server, json, secrets, urllib.parse, urllib.request, webbrowser ISSUER, CLIENT_ID = "https://phone.codeb.io", "my-app" REDIRECT = "http://localhost:8765/callback" verifier = secrets.token_urlsafe(48) challenge = base64.urlsafe_b64encode(hashlib.sha256(verifier.encode()).digest()).rstrip(b"=").decode() state = secrets.token_urlsafe(16) webbrowser.open(ISSUER + "/oauth2/v1/authorize?" + urllib.parse.urlencode({ "response_type": "code", "client_id": CLIENT_ID, "redirect_uri": REDIRECT, "scope": "openid profile email", "state": state, "nonce": secrets.token_urlsafe(16), "code_challenge": challenge, "code_challenge_method": "S256"})) class Callback(http.server.BaseHTTPRequestHandler): def do_GET(self): q = urllib.parse.parse_qs(urllib.parse.urlparse(self.path).query) assert q.get("state") == [state], "state mismatch" self.server.code = q["code"][0] self.send_response(200); self.end_headers(); self.wfile.write(b"Signed in. You can close this tab.") def log_message(self, *a): pass srv = http.server.HTTPServer(("localhost", 8765), Callback) srv.handle_request() body = urllib.parse.urlencode({"grant_type": "authorization_code", "client_id": CLIENT_ID, "redirect_uri": REDIRECT, "code": srv.code, "code_verifier": verifier}).encode() tokens = json.load(urllib.request.urlopen(ISSUER + "/oauth2/v1/token", body)) print(tokens["access_token"]) ## Endpoints All paths are relative to /api/v1. | Method | Path | What it does | |---|---|---| | GET | /forms | Forms the token may use; filter with ?released=true and ?q=. | | GET | /forms/{formId} | Settings, page count, links to the PDF and HTML versions. | | GET | /forms/{formId}/fields | Every field: type, name to submit, position, required, rule, options. | | GET | /forms/{formId}/schema | JSON Schema of the values, for code generators and AI agents. | | GET | /forms/{formId}/pdf | The empty released PDF form. | | POST | /forms/{formId}/validate | Checks values without submitting. | | POST | /forms/{formId}/fill | Filled PDF without submission, no e-mails (like Save in the web form). | | POST | /forms/{formId}/submissions | Submits the form: sealed PDF, e-mails, e-invoice. | | POST | /einvoices | ZUGFeRD / Factur-X / XRechnung invoice from structured data. | | POST | /forms/{formId}/prefill | Link to the web form with values filled in (DELETE /forms/{formId}/prefill/{prefillId} revokes it). | | GET / POST | /forms/{formId}/webhooks | List or create the webhooks of a form; PATCH, DELETE, /test and /rotate-secret per webhook (details). | | GET | /usage | Rate limit, API submissions today, webhook queue. | | GET | /field-types, /validation-rules, /me | Field types, validation rules, identity of the token. | ## Reading forms and fields List the released forms, then read the fields of one form. Each input field has a submitName: that is the key to use when you submit. Radio buttons share the name of their group; drop-downs list their options. curl -H "Authorization: Bearer $TOKEN" https://forms.example.com/api/v1/forms?released=true curl -H "Authorization: Bearer $TOKEN" https://forms.example.com/api/v1/forms/zugferd/fields?inputOnly=true Field types: textfield, dropdown, checkbox and radio take values; text, image, line and button are layout only. Positions are in points, measured like in the editor. ## Filling and submitting Send the values as an object of submitName and value. Check boxes take true or false, drop-downs and radio groups one of their options. The server checks required fields, options, length and validation rules first; if something is wrong it answers 422 with a list of errors and submits nothing. curl -X POST https://forms.example.com/api/v1/forms/contactrequest/submissions \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"values": {"Name": "Erika Muster", "Email": "erika@example.com", "Message": "Please call me back.", "Consent": true}}' Answer (201): { "submissionId": "0b6c1f2e9d4a4c51a3f0d2b7e8c91a44", "formId": "contactrequest", "status": "submitted", "pdf": { "fileName": "contactrequest.pdf", "size": 84211, "sha256": "…", "eInvoice": false, "data": "JVBERi0xLjc…" } } - /fill returns the filled PDF only: nothing is sealed, no e-mail is sent, required fields may stay empty. - Forms that require sign-in receive the verified identity of the token, exactly like after a sign-in in the browser. Other forms get it with "useIdentity": true. - Unknown field names are refused, so typing errors do not get lost. Send "ignoreUnknownFields": true to skip them instead. Fields you leave out keep their preset value, as in the browser. - Submitting needs the role user or admin; the server also limits the number of API submissions per day. ## E-invoices (ZUGFeRD / XRechnung) POST /einvoices takes an invoice as structured data, fills the server's invoice form and submits it. The answer is a PDF/A-3 with the EN 16931 XML embedded (ZUGFeRD / Factur-X; with a buyer reference (Leitweg-ID) for XRechnung). Line totals, VAT and the grand total are calculated when you leave them out. Dates are ISO (2026-10-11), amounts use a dot. curl -X POST https://forms.example.com/api/v1/einvoices \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "Accept: application/pdf" \ -o invoice-2026-0042.pdf -d '{ "invoice": { "number": "2026-0042", "date": "2026-10-11", "currency": "EUR", "dueDate": "2026-10-25", "taxPercent": 19 }, "seller": { "name": "Example Supplies GmbH", "street": "Musterstrasse 1", "postCode": "10115", "town": "Berlin", "country": "DE", "email": "billing@example.com", "vatId": "DE123456789" }, "buyer": { "name": "Example Hotel AG", "street": "Seestrasse 1", "postCode": "12345", "town": "Musterstadt", "country": "DE", "email": "accounts@example.com" }, "payment": { "iban": "DE02120300000000202051", "bic": "BYLADEM1001" }, "items": [ { "name": "Consulting (hours)", "quantity": 4, "netPrice": 120 }, { "name": "Travel flat rate", "netPrice": 80 } ] }' "action": "preview" returns the filled invoice without sending it. The invoice is e-mailed to the addresses in the data, like the invoice web form does. Full reference of the e-invoice API: every field with its EN 16931 business term, calculation and VAT rules, XRechnung checklist and errors. ## Webhooks A webhook sends every submission of a form to your HTTPS endpoint as JSON, optionally with the sealed PDF, a few seconds after the person clicked Submit. Messages are signed with HMAC-SHA256 according to Standard Webhooks (headers webhook-id, webhook-timestamp, webhook-signature) and retried for 21 hours. Managing webhooks needs the role admin. curl -X POST https://forms.example.com/api/v1/forms/contact/webhooks \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"url": "https://crm.example.com/hooks/eforms", "includePdf": true}' # answer 201 with "secret": "whsec_…" (shown once) Webhooks in detail: message format, signature checks in Node.js, Python, C# and PHP, retries and security. ## Prefilled links A prefilled link opens the web form with values already filled in, for example a contract with the customer number and address that the customer only checks and signs. The values stay on the server; the link carries a random token that works for this form only and expires (default 7 days, at most 90). curl -X POST https://forms.example.com/api/v1/forms/contract/prefill \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"values": {"CustomerNo": "K-1042", "Surname": "Muster", "Email": "erika@example.com"}, "expiresInHours": 72, "lock": true}' { "id": "pf_1c9e…", "formId": "contract", "url": "https://forms.example.com/pdfforms.aspx?fid=contract&web=1&prefill=Qm9x…", "expiresAt": "2026-10-15T09:30:00Z", "lock": true, "fields": 3 } - Values are checked like a submission (options, length, rules), but fields may stay empty. "lock": true makes the prefilled text fields read-only in the browser (a convenience against typing errors, not a security control). The values may have at most 64 KB in total. - The browser's remembered entries do not overwrite a prefilled link. If the form requires sign-in, the link survives the sign-in. - Send the link only to the person it is meant for: whoever has it sees the values. DELETE /forms/{formId}/prefill/{id} revokes it. - Creating links always needs the role user or admin. ## Usage and rate limits Every authenticated answer carries the caller's limit: X-RateLimit-Limit (requests per minute), X-RateLimit-Remaining and X-RateLimit-Reset (seconds until the window restarts). GET /usage returns the same, plus (for user and admin) the API submissions of today against the daily cap and (for admins) the webhook queue. curl -H "Authorization: Bearer $TOKEN" https://forms.example.com/api/v1/usage { "user": "erika@example.com", "role": "admin", "rateLimit": { "limitPerMinute": 120, "remaining": 117, "resetSeconds": 42 }, "apiSubmissions": { "today": 12, "limitPerDay": 1000, "remaining": 988, "resetsAt": "2026-10-13T00:00:00Z" }, "webhooks": { "enabled": true, "queued": 0, "failedLast7Days": 0 } } ## Errors and limits Every error is a problem details object with type, title, status and detail; validation errors add a list of fields. | Status | Code | Meaning | |---|---|---| | 400 | invalid_json | The body is not a JSON object. | | 401 | invalid_token, invalid_request | Token missing, expired, for another application, or from an unknown server. | | 403 | insufficient_scope, local_account | Required scope missing, or the name belongs to a local account. | | 404 | form_not_found | Unknown form, or a form of another group. | | 409 | form_not_released | The form has not been released yet. | | 422 | validation_failed | Values missing or invalid; see errors. | | 403 | role_required | Submitting and prefilled links need the role user or admin; webhooks need admin. | | 403 | webhooks_disabled, prefill_disabled | Webhooks or prefilled links are switched off on this server. | | 409 | too_many_webhooks | The form already has the maximum number of webhooks (default 10). | | 404 | not_found | Unknown API path. | | 405 | method_not_allowed | Wrong HTTP method for this path. Where PATCH or DELETE cannot get through, send POST with the header X-HTTP-Method-Override. | | 413 / 415 | too_large, unsupported_media_type | Body larger than 10 MB, or not JSON. | | 422 | not_an_invoice_form, too_many_items | The chosen form has no invoice lines, or fewer lines than the invoice. | | 429 | rate_limited, daily_limit | Too many requests (default 120 per minute and user), or the daily cap of API submissions; wait for Retry-After. | | 502 | form_processing_failed | The form could not be processed (e.g. e-mail server not reachable). | | 500 | server_error | Error on the server; details are in the server log. | | 503 | storage_busy | The webhook configuration is being written by another request; try again. | | 503 | api_disabled, issuer_unavailable, loopback_not_configured | API switched off, sign-in server not reachable, or the internal address of the server is not set. | ## What the API covers We compared the API with the APIs of common form builders and PDF services. They typically offer: listing forms and their questions, reading and creating submissions, webhooks on new submissions, and filling or reading PDF form data. The CodeB eForms Server API covers: - Forms and fields, including field types, positions, validation rules and a JSON Schema per form. - Submissions with the full processing of the web form: sealed and optionally signed PDF, e-mails and attachment rules. - PDF filling without submission, and the empty PDF form. - E-invoices (ZUGFeRD / Factur-X / XRechnung) from structured data, a feature form builders usually do not have. - Standards-based security: OAuth 2.0 bearer tokens of your own OpenID Connect servers, no extra API keys. - Webhooks for every submission, signed according to Standard Webhooks, with retries and failure e-mails. - Prefilled links that open a form with values filled in, and a usage endpoint with rate-limit headers. The server deliberately keeps no copy of submitted data, so there is no endpoint to list past submissions; use a webhook to receive each submission in your own system. ## Questions and answers ### How do I get a token for the API? Sign in with the authorization code flow (with PKCE) at one of the OpenID Connect servers configured on the form server, for example phone.codeb.io, and use the access token. Tokens issued for the form server's client ID are accepted; an administrator can allow the client IDs of further applications. ### Is there an OpenAPI or Swagger description? Yes. Every server publishes OpenAPI 3.1 at /api/v1/openapi, and you can download it from this page. Import it into Postman, Swagger UI or a code generator. ### Can I create ZUGFeRD or XRechnung invoices through the API? Yes. POST /api/v1/einvoices takes seller, buyer, lines and VAT as JSON and returns a PDF/A-3 with the EN 16931 XML embedded. With a buyer reference (Leitweg-ID) it meets XRechnung. ### Does a submission through the API differ from one in the browser? No. The API hands the values to the same processing as the web form, so the sealed PDF, the signature, the e-mails and the e-invoice are the same. ### Can I list submitted forms? No. The server does not keep submitted data; the result goes to the configured recipients and back to the caller. To collect submissions in your own system, register a webhook: every submission is then sent to your endpoint as signed JSON. ### Does the API support webhooks? Yes. POST /api/v1/forms/{formId}/webhooks registers an HTTPS endpoint that receives every submission of the form as JSON, signed with HMAC-SHA256 according to Standard Webhooks and retried for 21 hours. See the webhooks page for the message format and signature checks. ### Can I send someone a form that is already filled in? Yes. POST /api/v1/forms/{formId}/prefill returns a link that opens the web form with your values filled in. The link works for that form only and expires after 7 days by default. ## Try the API Ask for test credentials for our online form server and try the API with your own forms. --- # E-invoice API: E-invoice API: ZUGFeRD and XRechnung from JSON. URL: https://www.form-provider.com/en/einvoice-api.html One API call turns structured invoice data into a legally compliant electronic invoice: a PDF/A-3 that people read like any PDF, with the invoice data embedded as XML according to EN 16931 (ZUGFeRD / Factur-X). With a buyer reference (Leitweg-ID) the invoice meets the XRechnung rules for German public authorities. The endpoint fills the invoice form of your server and submits it, so the invoice is sealed, signed if configured, and e-mailed like an invoice entered in the browser. ## In short - One call: POST /api/v1/einvoices with seller, buyer, lines and VAT as JSON. - Result: a ZUGFeRD / Factur-X PDF/A-3 with EN 16931 XML; with a buyer reference (Leitweg-ID) for XRechnung. - Calculated for you: line totals, VAT and grand total when you leave them out; "action": "preview" returns the invoice without sending it. ## Contents 1. How it works 2. Smallest request 3. Complete example (XRechnung) 4. Field reference 5. Amounts, VAT and rounding 6. Payment 7. XRechnung checklist 8. The answer 9. Using your own invoice form 10. Limits and errors 11. Questions and answers ## How it works - Your software sends POST /api/v1/einvoices with a bearer token (see Getting a bearer token) and the invoice as JSON. - The server checks the data, calculates missing totals and maps every value to the fields of its invoice form (by default the form zugferd). - The form is submitted through the normal form processing. It creates the EN 16931 XML (Cross Industry Invoice, ZUGFeRD / Factur-X profile EN 16931, written following the KoSIT rules used for XRechnung), embeds it into a PDF/A-3 and seals the PDF. - The PDF goes back to your software (as Base64 in JSON, or as the file itself with Accept: application/pdf) and, like the web form, by e-mail to the business owner of the form and to the e-mail addresses in the invoice (seller and buyer). "action": "preview" stops after step 2: you receive the filled invoice form as PDF, nothing is sealed and no e-mail is sent. Use it to check a layout or your mapping. ## Smallest request Invoice number, seller, buyer and at least one line are required. The invoice date defaults to today, the currency to the form's preset (EUR on the sample form), and all totals are calculated. curl -X POST https://forms.example.com/api/v1/einvoices \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "Accept: application/pdf" \ -o invoice.pdf -d '{ "invoice": { "number": "2026-0042", "taxPercent": 19 }, "seller": { "name": "Example Supplies GmbH", "street": "Musterstrasse 1", "postCode": "10115", "town": "Berlin", "country": "DE", "vatId": "DE123456789" }, "buyer": { "name": "Example Hotel AG", "street": "Seestrasse 1", "postCode": "12345", "town": "Musterstadt", "country": "DE" }, "items": [ { "name": "Consulting (hours)", "quantity": 4, "netPrice": 120 } ] }' ## Complete example (XRechnung) An invoice to a German public authority, with Leitweg-ID, contact data, delivery date and SEPA payment. Dates are ISO 8601 (yyyy-MM-dd; dd.MM.yyyy is accepted too), amounts are numbers with a dot as decimal separator. { "action": "submit", "invoice": { "number": "2026-0042", "date": "2026-10-11", "currency": "EUR", "dueDate": "2026-10-25", "deliveryDate": "2026-10-09", "paymentTerms": "14 days net", "buyerReference": "04011000-12345-34", "buyerOrderReference": "PO-7781", "taxPercent": 19, "taxCategory": "S", "note": "Thank you for your order." }, "seller": { "name": "Example Supplies GmbH", "contactName": "Erika Muster", "street": "Musterstrasse 1", "postCode": "10115", "town": "Berlin", "country": "DE", "phone": "+49 30 1234567", "email": "billing@example.com", "vatId": "DE123456789" }, "buyer": { "name": "City of Musterstadt", "contactName": "Max Beispiel", "street": "Rathausplatz 1", "postCode": "12345", "town": "Musterstadt", "country": "DE", "email": "invoices@example.org" }, "payment": { "iban": "DE02120300000000202051", "bic": "BYLADEM1001", "accountName": "Example Supplies GmbH" }, "items": [ { "name": "Consulting (hours)", "quantity": 4, "netPrice": 120, "sellerAssignedId": "C-100" }, { "name": "Travel flat rate", "netPrice": 80 } ] } ## Field reference Every JSON field, the EN 16931 business term (BT) it fills and the field name on the invoice form. Required fields are marked. | JSON | Meaning | EN 16931 | Form field | |---|---|---|---| | invoice.number required | Invoice number | BT-1 | InvoiceID | | invoice.date | Invoice date (default: today) | BT-2 | date | | invoice.currency | Currency, ISO 4217 (EUR, CHF, …) | BT-5 | InvoiceCurrencyCode | | invoice.dueDate | Payment due date | BT-9 | DueDate | | invoice.buyerReference | Buyer reference; for XRechnung the Leitweg-ID | BT-10 | BuyerReference | | invoice.buyerOrderReference | Purchase order number of the buyer | BT-13 | BuyerOrderReference | | invoice.paymentTerms | Payment terms as text | BT-20 | PaymentTerms | | invoice.note | Invoice note | BT-22 | InvoiceNote | | invoice.deliveryDate | Actual delivery date | BT-72 | DeliveryDate | | invoice.paymentReference | Remittance information (only if the form has the field) | BT-83 | PaymentReference | | invoice.taxPercent | VAT rate in percent for the whole invoice | BT-152 / BT-119 | TAXPercent | | invoice.taxCategory | VAT category: S, Z, E, AE or G (see below) | BT-151 / BT-118 | TaxCategory | | invoice.taxExemptionReason | Reason for E, AE, G | BT-120 | TaxExemptionReason | | seller.name required | Seller name | BT-27 | SellerName | | seller.street, street2 | Address lines | BT-35, BT-36 | SellerStreet1, SellerStreet2 | | seller.postCode, town, country | Post code, town, country (ISO 3166-1, e.g. DE) | BT-38, BT-37, BT-40 | SellerPostCode, SellerTown, SellerCountry | | seller.vatId | VAT identification number | BT-31 | SellerVAT | | seller.contactName, phone | Contact person and phone | BT-41, BT-42 | SellerPersonName, SellerPhone | | seller.email | Seller e-mail as electronic address | BT-34 | SellerEmail | | buyer.name required | Buyer name | BT-44 | BuyerName | | buyer.street, street2, postCode, town, country | Buyer address | BT-50 to BT-55 | BuyerStreet1 … BuyerCountry | | buyer.vatId | Buyer VAT identification number | BT-48 | BuyerVAT | | buyer.contactName, phone | Contact at the buyer | BT-56, BT-57 | BuyerPersonName, BuyerPhone | | buyer.email | Buyer e-mail as electronic address | BT-49 | BuyerEmail | | payment.iban, bic, accountName | Bank account for the SEPA credit transfer | BT-84, BT-86, BT-85 | IBAN, BIC, AccountName | | items[].name required | Item name | BT-153 | ItemName1, ItemName2, … | | items[].quantity | Quantity (default 1, unit C62 = piece) | BT-129 | BilledQuantity1, … | | items[].netPrice required | Net unit price | BT-146 | NetPriceProductTradePrice1, … | | items[].lineTotal | Line net amount (default: quantity × net price) | BT-131 | LineTotalAmount1, … | | items[].sellerAssignedId | Seller's item number (only if the form has the field) | BT-155 | SellerAssignedID1, … | | totals.lineTotal, taxTotal, grandTotal | Totals; calculated when missing | BT-106, BT-110, BT-112 | LineTotalAmount, TaxTotalAmount, GrandTotalAmount | ## Amounts, VAT and rounding - Line amount = quantity × net price, rounded to 2 decimals (half away from zero), unless you send lineTotal. - Sum of lines = sum of the line amounts; it is also the taxable amount and the total without VAT. - VAT = sum of lines × taxPercent / 100, rounded to 2 decimals. Total = sum of lines + VAT; the amount due equals the total. - Totals you send in totals win over the calculation, so you can pass the exact figures of your accounting system. - One VAT rate applies to the whole invoice. For invoices with several VAT rates, send one invoice per rate or ask us about the ZUGFeRD Pro SDK. - Numbers: 1234.5 or "1234.50". A comma is refused, so "12,50" can never become 1250. ### VAT categories - S standard rate (default). With a rate of 0 it becomes Z. - Z zero rated goods. - E exempt from VAT; without taxExemptionReason the reason "Steuerfreie Leistung" is used. - AE reverse charge (exemption code VATEX-EU-AE); default reason "Steuerschuldnerschaft des Leistungsempfängers". - G export outside the EU (VATEX-EU-G). For E, AE and G the rate is set to 0. ## Payment With an iban the invoice carries a SEPA credit transfer (payment means code 58) with BIC and account name. Without an IBAN the payment means is "not defined" (code 1). Payment terms (paymentTerms) and due date (dueDate) are written in any case; without a due date the invoice date is used. ## XRechnung checklist Invoices to German public authorities must follow XRechnung. Send at least: - invoice.buyerReference = the Leitweg-ID of the authority (without it the server writes a generated reference, which an authority will reject). - seller.email and buyer.email (electronic addresses), seller.contactName, seller.phone. - seller.vatId, complete addresses with country codes, invoice.dueDate or paymentTerms. - Payment data (payment.iban) if the authority pays by transfer. The XML is written following the KoSIT rules. Check your first invoices once with the KoSIT validator or a viewer of your choice. ## The answer 201 Created with the submission ID, the PDF and the totals that were used: HTTP/1.1 201 Created { "submissionId": "7f3c2a9e0d5b4e1fa2c8b6d4e9f01a23", "formId": "zugferd", "action": "submit", "status": "submitted", "pdf": { "fileName": "zugferd.pdf", "contentType": "application/pdf", "size": 152331, "sha256": "…", "eInvoice": true, "data": "JVBERi0xLjc…" }, "totals": { "lineTotal": 560.00, "taxTotal": 106.40, "grandTotal": 666.40, "currency": "EUR" }, "notOnForm": [ "PaymentReference", "SellerAssignedID1", "SellerAssignedID2" ] } - pdf.eInvoice is true when the e-invoice XML is embedded in the PDF. - notOnForm lists values the chosen form has no field for (they are not part of the invoice). - With Accept: application/pdf (or "returnPdf": "binary") the answer is the PDF itself; the header X-Submission-Id carries the ID. "returnPdf": "none" leaves out the PDF data. - "action": "preview" answers 200 with the filled, unsent invoice. ## Using your own invoice form By default the server uses its invoice form (setting Form for e-invoices, preset zugferd). Send "formId" to use another one, for example an invoice form with your letterhead. The form must be released and needs fields with the names in the field reference above; lines are numbered from 1 (or from 0). The number of ItemName… fields is the maximum number of lines: the sample form has 8. Design the form in the editor, name the fields as listed, release it, then check the mapping with "action": "preview". GET /api/v1/forms/{formId}/fields shows the field names of a form. ## Limits and errors Errors come as problem details (application/problem+json); see also the error list of the API. | Status | Code | Meaning | |---|---|---| | 422 | validation_failed | A required value is missing (number, seller or buyer name, line name or price), a date or number cannot be read, or a value does not fit the form (e.g. unknown currency or country in a drop-down). | | 422 | too_many_items | More lines than the form has room for. | | 422 | not_an_invoice_form | The chosen form has no invoice line fields. | | 403 | role_required | Creating invoices needs the role user or admin. | | 404 / 409 | form_not_found, form_not_released | The invoice form does not exist for this token, or is not released. | | 429 | rate_limited, daily_limit | Too many requests, or the daily cap of API submissions is reached. | | 502 | form_processing_failed | The invoice could not be created or sent; nothing was delivered. | ## Questions and answers ### Which ZUGFeRD profile does the API create? The EN 16931 profile (called COMFORT in ZUGFeRD 1), Cross Industry Invoice XML embedded in a PDF/A-3, identical to Factur-X. The XML is written following the KoSIT rules that XRechnung uses. ### How do I create an XRechnung? Send the Leitweg-ID of the public authority as invoice.buyerReference and fill in the e-mail addresses and contact data of seller and buyer. The API then creates an EN 16931 invoice that meets the XRechnung rules, embedded in the PDF. ### Can I send the totals of my accounting system? Yes. Values in totals (lineTotal, taxTotal, grandTotal) and items[].lineTotal win over the calculation. ### Is the invoice e-mailed automatically? Yes, like the invoice web form: to the business owner of the form and to the e-mail addresses in the data. Use "action": "preview" to get the PDF without sending. ### Can an invoice have several VAT rates? Not through this endpoint: one rate applies to the whole invoice. Send one invoice per rate, or use the ZUGFeRD Pro SDK for complex invoices. ## Create your first e-invoice Ask for test credentials and try the e-invoice API on our online server. --- # Webhooks: Webhooks: every submission straight into your system. URL: https://www.form-provider.com/en/webhooks.html A webhook sends each new submission of a form to an address of your choice, a few seconds after the person clicked Submit: CRM, ticket system, ERP, a low-code flow or your own service. The message is JSON, carries all values and optionally the sealed PDF, and is signed so your system can prove it came from your form server. Signing follows the open Standard Webhooks specification, so ready-made libraries for many languages can check it. Messages that cannot be delivered are retried for 21 hours. ## In short - Event: submission.created for every real submission, as JSON, optionally with the sealed PDF. - Signature: Standard Webhooks, HMAC-SHA256 over id, timestamp and body (headers webhook-id, webhook-timestamp, webhook-signature). - Delivery: 7 attempts over about 21 hours, HTTPS only, private networks refused, failure e-mail at the end. ## Contents 1. How it works 2. Setting up a webhook 3. The message 4. Checking the signature 5. Delivery and retries 6. Managing webhooks 7. Security and privacy 8. Questions and answers ## How it works - Register an address for a form through the REST API (role admin). The answer contains a signing secret that starts with whsec_; it is shown only once. - Someone submits the form in the browser, from the PDF or through the API. The server creates the sealed PDF as usual and queues one message per webhook. The person does not wait for your system. - Your endpoint receives a POST with the values as JSON and three headers: webhook-id, webhook-timestamp and webhook-signature. - Check the signature with the secret, then answer with any 2xx status within 15 seconds. Do longer work after answering. Webhooks complement the e-mails of the form: the business owner still gets the PDF and XML by e-mail, unless the form is set up without e-mail. ## Setting up a webhook You need an access token of a user with the role admin in the form's group (see getting a bearer token). The address must use https:// and be reachable from the internet; addresses in private networks are refused unless the administrator allows them. curl -X POST https://forms.example.com/api/v1/forms/contact/webhooks \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"url": "https://crm.example.com/hooks/eforms", "description": "CRM import", "includePdf": true, "failureEmails": ["it@example.com"]}' HTTP/1.1 201 Created { "id": "wh_3f2a9c1d0b7e4a6c5d8e", "formId": "contact", "url": "https://crm.example.com/hooks/eforms", "events": ["submission.created"], "active": true, "includePdf": true, "failureEmails": ["it@example.com"], "secret": "whsec_MfKQ9r8GKYqrTwjUPD8ILPZIo2LaLaSw", … } # send a test message and see what the receiver answered curl -X POST -H "Authorization: Bearer $TOKEN" \ https://forms.example.com/api/v1/forms/contact/webhooks/wh_3f2a9c1d0b7e4a6c5d8e/test { "delivered": true, "httpStatus": 200, "durationMs": 184 } - includePdf adds the submitted PDF as Base64 (up to 10 MB) to every message. Without it the message carries the values only. - failureEmails (up to five addresses) are told when a message could not be delivered after all attempts. - Store the secret in your system's secret store. Lost it? POST …/webhooks/{id}/rotate-secret issues a new one; the old one stops working at once. ## The message Each message is a JSON object with type, timestamp and data. The event submission.created carries the form ID, the submission ID (the same the API returns for API submissions), the submission reference, the time and the values by field name. Control fields of the web form (bot check, passwords of the encrypted archive) are never included. POST /hooks/eforms HTTP/1.1 Host: crm.example.com Content-Type: application/json User-Agent: CodeB-eForms-Server-Webhooks/1.0 webhook-id: msg_2b8f0c6e9a1d4f7b3c5e8a90 webhook-timestamp: 1791802200 webhook-signature: v1,K5oZfzN95Z9UVu1EsfQmfVNQhnkZ2pj9o9NDN/H/pI4= { "type": "submission.created", "timestamp": "2026-10-12T09:30:00Z", "data": { "formId": "contact", "submissionId": "5d0c2f4e8b1a4c7e9f3b2a1d6e5c4b3a", "reference": "contact/118/26", "submittedAt": "2026-10-12T09:30:00Z", "values": { "FirstName": "Erika", "Surname": "Muster", "Email": "erika@example.com" }, "pdf": { "fileName": "contact.pdf", "contentType": "application/pdf", "size": 48211, "data": "JVBERi0xLjcK…" } } } The test message has the type webhook.test. The OpenAPI description lists both events under webhooks, with their JSON Schema, so code generators can create the receiving types. ## Checking the signature The signature is v1, followed by the Base64 HMAC-SHA256 of webhook-id + "." + webhook-timestamp + "." + body. The key is the Base64-decoded part of the secret after whsec_. Use the raw request body, before any JSON parsing, and compare in constant time. Reject messages older than five minutes, and keep the webhook-id of processed messages to ignore repeats. ### Node.js const crypto = require("node:crypto"); // rawBody: the request body exactly as received (string), before any JSON parsing function verifyWebhook(secret, headers, rawBody) { const id = headers["webhook-id"], ts = headers["webhook-timestamp"]; if (!id || !ts || Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false; const key = Buffer.from(secret.replace(/^whsec_/, ""), "base64"); const expected = crypto.createHmac("sha256", key).update(`${id}.${ts}.${rawBody}`).digest("base64"); return (headers["webhook-signature"] || "").split(" ").some(part => { const [version, sig] = part.split(","); return version === "v1" && sig && sig.length === expected.length && crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected)); }); } ### Python import base64, hashlib, hmac, time def verify_webhook(secret: str, headers: dict, raw_body: bytes) -> bool: msg_id, ts = headers.get("webhook-id", ""), headers.get("webhook-timestamp", "0") if not msg_id or abs(time.time() - int(ts)) > 300: return False key = base64.b64decode(secret.removeprefix("whsec_")) mac = hmac.new(key, f"{msg_id}.{ts}.".encode() + raw_body, hashlib.sha256).digest() expected = base64.b64encode(mac).decode() return any(hmac.compare_digest(part[3:], expected) for part in headers.get("webhook-signature", "").split() if part.startswith("v1,")) # or with the reference library: pip install standardwebhooks # from standardwebhooks import Webhook; Webhook(secret).verify(raw_body, headers) ### C# (.NET) using System.Security.Cryptography; using System.Text; static bool VerifyWebhook(string secret, string id, string ts, string signatures, string rawBody) { if (Math.Abs(DateTimeOffset.UtcNow.ToUnixTimeSeconds() - long.Parse(ts)) > 300) return false; var key = Convert.FromBase64String(secret.StartsWith("whsec_") ? secret.Substring(6) : secret); using var hmac = new HMACSHA256(key); var expected = Convert.ToBase64String(hmac.ComputeHash(Encoding.UTF8.GetBytes($"{id}.{ts}.{rawBody}"))); foreach (var part in signatures.Split(' ')) { var p = part.Split(',', 2); if (p.Length == 2 && p[0] == "v1" && CryptographicOperations.FixedTimeEquals(Encoding.ASCII.GetBytes(p[1]), Encoding.ASCII.GetBytes(expected))) return true; } return false; } ### PHP function verify_webhook(string $secret, string $id, string $ts, string $signatures, string $rawBody): bool { if (abs(time() - (int)$ts) > 300) return false; $key = base64_decode(preg_replace('/^whsec_/', '', $secret)); $expected = base64_encode(hash_hmac('sha256', "$id.$ts.$rawBody", $key, true)); foreach (explode(' ', $signatures) as $part) { [$version, $sig] = array_pad(explode(',', $part, 2), 2, ''); if ($version === 'v1' && hash_equals($expected, $sig)) return true; } return false; } // $rawBody = file_get_contents('php://input'); ## Delivery and retries A message counts as delivered when your endpoint answers with a 2xx status within 15 seconds. Otherwise it is sent again with the same webhook-id: | Attempt | When | Note | |---|---|---| | 1 | At once, a few seconds after the submission | Redirects are not followed. | | 2 | 1 minute later | | | 3 | 5 minutes later | | | 4 | 30 minutes later | | | 5 | 2 hours later | | | 6 | 6 hours later | | | 7 | 12 hours later | About 21 hours after the submission. Then the failure e-mail goes out and the message is kept for 7 days for the administrator. | | – | Answer 410 Gone | No further attempts for this message. | ## Managing webhooks All paths are relative to /api/v1 and need the role admin. PATCH and DELETE also work as POST with the header X-HTTP-Method-Override. | Method | Path | What it does | |---|---|---| | GET | /forms/{formId}/webhooks | The webhooks of a form, with the result of the last delivery. | | POST | /forms/{formId}/webhooks | Create a webhook; the answer contains the secret. | | GET | /forms/{formId}/webhooks/{webhookId} | One webhook. | | PATCH | /forms/{formId}/webhooks/{webhookId} | Change address, description, includePdf, failureEmails or switch it off with "active": false (messages still waiting are dropped). | | DELETE | /forms/{formId}/webhooks/{webhookId} | Delete it; waiting messages are dropped. | | POST | /forms/{formId}/webhooks/{webhookId}/test | Send webhook.test now and show the answer. | | POST | /forms/{formId}/webhooks/{webhookId}/rotate-secret | New secret. | | GET | /usage | Messages waiting and failed messages of the last 7 days (admins). | ## Security and privacy - HTTPS only, with certificate check. Addresses that point to the form server itself or to private networks (10.x, 192.168.x, 172.16–31.x, link-local, unique local IPv6) are refused, also when a host name changes its address later. An administrator can allow internal receivers (setting Webhooks → Allow addresses in private networks). - Only admins of a form's group can add webhooks, because a webhook receives every value of every submission. - Secrets are stored encrypted with the Windows data protection of the server (DPAPI). After moving the server to another machine, rotate them. - Data on the server: a message stays on the server only until it is delivered. Messages that fail all attempts are deleted after 7 days (adjustable). Apart from that, the server keeps no copy of submissions by default. - Each message is an ordinary HTTPS request from your form server, so your firewall can allow its address. For a hosted server, ask us for the address. ## Questions and answers ### What is a form webhook? An HTTPS request the form server sends to your system each time a form is submitted. It carries the submitted values as JSON (and optionally the PDF), so your CRM, ERP or workflow receives the data without anyone copying it from an e-mail. ### How do I know a webhook really comes from my form server? Every message is signed with HMAC-SHA256 and a secret only you and the form server know, following the Standard Webhooks specification. Check the webhook-signature header as shown on this page or with a Standard Webhooks library, and reject messages older than five minutes. ### What happens if my system is down? The message is retried after 1 minute, 5 minutes, 30 minutes, 2, 6 and 12 hours, with the same webhook-id. If all seven attempts fail, the failure e-mail addresses of the webhook are told and the message is kept for 7 days. ### Can I receive the PDF too? Yes. With "includePdf": true each message carries the submitted, sealed PDF as Base64, up to 10 MB. ### Do submissions through the API trigger webhooks? Yes. Every real submission does: from the browser, from the PDF in Adobe Reader and through the API. Filling a PDF with /fill or Save in the browser does not. ### Can I use webhooks with Zapier, Make or Power Automate? Yes. Use the catch-hook or HTTP trigger URL of the flow as the webhook address. If the tool cannot check signatures, at least use a long, secret URL and check the webhook-timestamp. ### How many webhooks can a form have? Up to 10 by default; the administrator can change the limit. ## Connect your forms Ask for test credentials and connect a form of our online server to your own system. --- # Samples: Try it before you decide. URL: https://www.form-provider.com/en/samples.html These sample forms run on this server. Open them in the format you like, fill them in and submit them: you receive the result as a sealed PDF. ## In short - No account needed: the sample forms run on this server; fill them in and submit them. - Formats: each sample opens as responsive HTML, static HTML or fillable PDF. - Result: you receive the submission as a sealed PDF by e-mail; the ZUGFeRD sample returns an e-invoice. ## Sample forms - **My Health: doctor access**: Consent form with two handwritten signatures, patient and doctor, on touch screen or with the mouse. https://www.form-provider.com/pdfforms.aspx?fid=myhealth (add &pdf=1, &static=1 or &web=1) - **Rental declaration**: Two pages. The rental contract must be attached before the form can be submitted; images become PDF pages, other files are zipped. https://www.form-provider.com/pdfforms.aspx?fid=rentaldeclaration (add &pdf=1, &static=1 or &web=1) - **Property visit confirmation**: Agent and customer confirm a property visit and both sign on the screen. https://www.form-provider.com/pdfforms.aspx?fid=propertyvisit (add &pdf=1, &static=1 or &web=1) - **German hotel registration (Meldeschein)**: In German. Guest registration for hotels under §§ 29, 30 of the German Federal Registration Act (BMG), with a handwritten signature on the screen. https://www.form-provider.com/pdfforms.aspx?fid=meldeschein (add &pdf=1, &static=1 or &web=1) - **ZUGFeRD test invoice**: Fill in an invoice and receive a ZUGFeRD / XRechnung e-invoice: PDF/A-3 with embedded EN 16931 XML. Test data only. https://www.form-provider.com/pdfforms.aspx?fid=zugferd (add &pdf=1, &static=1 or &web=1) ## What is ZUGFeRD? ZUGFeRD is the German-French standard for electronic invoices, identical to Factur-X in France. A ZUGFeRD invoice is a PDF/A-3 that people read like any PDF, with the invoice data embedded as XML according to the European standard EN 16931, so accounting software can book it without retyping. The XRechnung profile is required for invoices to German public authorities. In Germany, businesses have had to be able to receive e-invoices since 1 January 2025; the obligation to issue them follows in stages until 2028. With the ZUGFeRD test invoice above you see it in practice: every submission is turned into a valid e-invoice. Companies without their own invoicing software can design their invoice template on the eForms Server and send compliant invoices this way. For more on e-invoicing, and for our tools to create, read and convert ZUGFeRD and XRechnung invoices, also as a web service, visit www.zugferdpro.com. ## More sample forms - **Contact request**: A short contact form with consent check box. https://www.form-provider.com/pdfforms.aspx?fid=contactrequest (add &pdf=1, &static=1 or &web=1) - **Event registration**: Registration with ticket choice, workshops and dietary options. https://www.form-provider.com/pdfforms.aspx?fid=eventregistration (add &pdf=1, &static=1 or &web=1) - **New employee data sheet**: Personal and bank details for HR onboarding. https://www.form-provider.com/pdfforms.aspx?fid=employeeonboarding (add &pdf=1, &static=1 or &web=1) - **Expense claim**: Travel and expense report with totals. https://www.form-provider.com/pdfforms.aspx?fid=expenseclaim (add &pdf=1, &static=1 or &web=1) ## Frequently asked questions ### Is there a digital Meldeschein for hotels? Yes. The sample "German hotel registration (Meldeschein)" shows the registration form for guests under §§ 29 and 30 of the German Federal Registration Act (BMG). Guests fill it in on a tablet at the reception or on their own phone and sign by hand on the screen; the hotel receives a sealed PDF and the data as XML. Since 1 January 2025 the form is only required for foreign guests. ### Can I test the sample forms without an account? Yes. The sample forms are public: open one, fill it in with test data and submit it. To design your own forms, ask for a free online presentation or a free 30-day trial at info@aloaha.com. ### What happens to the data I enter in a sample form? It is turned into a sealed PDF and sent to the e-mail address you enter and to the form owner. The server does not keep a copy. Please use test data only. ### Which sample forms are available? A hotel guest registration (Meldeschein), a medical consent with two signatures, a rental declaration with attachment, a property visit confirmation, a ZUGFeRD invoice, and contact, event, onboarding and expense forms. Each opens as responsive HTML, static HTML or fillable PDF. --- # Test online: Test the form server online, with your own forms. URL: https://www.form-provider.com/en/aloaha-demo-form-server.html Anyone can try the CodeB eForms Server on our online server. Write to us and we send you test credentials: you design your own forms in the browser, publish them and fill them in, on the desktop and on your phone. Free of charge and without obligation. Please use test data only. ## In short - Who: anyone who wants to evaluate the CodeB eForms Server can ask for test credentials by e-mail. - What: design your own forms, publish them as PDF and HTML, sign, create e-invoices and call the REST API. - Data: please use test data only; submissions are sent by e-mail and not kept on the server. ## How to get your test access 1. Write to info@aloaha.com with the subject "Test credentials" and tell us briefly what you would like to try. 2. We set up a test account for you and send you the address of the server and your credentials. 3. Sign in, open the form library and create your first form, or start from one of the examples. 4. Release the form and fill it in: you receive the sealed PDF by e-mail. ## What you can try - **Form editor**: Design a form in the WYSIWYG editor, on the desktop or on a tablet or phone. - **PDF and HTML**: Publish the same form as fillable PDF, responsive HTML and static HTML. - **Signatures**: Handwritten signatures on the screen, sealed PDFs, timestamps. - **E-invoices**: Turn an invoice form into ZUGFeRD / XRechnung e-invoices. - **Sign-in and EUDI Wallet**: Forms that require sign-in and are pre-filled with verified data. - **REST API**: List forms and fields, submit data and create e-invoices from your own software. ## Good to know - The test server is for trying things out. Please use test data only, no real personal data. - Submitted forms are sent by e-mail to the addresses you enter; the server keeps no copy. - You would like to see it first? We are happy to show you the form server in a free online presentation. - For your own operation the form server runs on Windows Server and IIS in your data centre, or hosted by Aloaha. ## Questions and answers ### Who can get test credentials? Anyone: companies, public authorities, developers and partners. Write to info@aloaha.com and tell us briefly what you would like to test. ### What does the test cost? Nothing. The test access is free of charge and without obligation. ### Can I test the REST API too? Yes. Tell us that you want to test the API: you get a sign-in account whose token the API accepts, and can list forms, submit data and create e-invoices. ### Can I try the sample forms without credentials? Yes. The sample forms are public; credentials are only needed to design your own forms. ### How fast do I get test credentials? We answer requests by e-mail; write to info@aloaha.com with your name and organisation. ## Ask for your test credentials One e-mail is enough. --- # Legal: Imprint URL: https://www.form-provider.com/en/imprint.html Legal information for this website and the product CodeB eForms Server. The provider is Aloaha Limited, a company registered in Malta. The same legal entity also operates www.aloaha.com, www.zugferdpro.com and www.codeb.io. ## Provider Aloaha Limited “Helgoland” 45, Triq Gio Felice Inglott Pembroke PBK1131 Malta ## Company details | Item | Value | |---|---| | Legal form | Private Limited Company (Limited) | | Registered office | Pembroke, Malta | | Jurisdiction | Republic of Malta, EU member state | | VAT ID | MT14814406 | ## Contact E-mail: info@aloaha.com Phone: +49 541 3859 4554 and +49 151 5761 0183 Availability: Monday to Friday during normal business hours (CET), in German and English Internet: www.aloaha.com Every e-mail to info@aloaha.com is read and answered by a person from engineering or sales. ## Responsible for the content Office of the Managing Director, Aloaha Limited, by post at the address above or by e-mail via info@aloaha.com. ## Consumer dispute resolution Aloaha Limited is neither obliged nor willing to take part in dispute resolution proceedings before a consumer arbitration board. ## Trademarks “Aloaha”, “CodeB”, “CodeB Identity Solutions” and the CodeB logo are trademarks of Aloaha Limited. Third-party trademarks, among them Adobe, Acrobat, ZUGFeRD, Factur-X, Microsoft, Windows, Azure and .NET, belong to their respective owners and are named for descriptive purposes only. ## Liability for content The content of this website was created with great care. Aloaha Limited does not, however, guarantee that it is correct, complete or up to date. As a service provider we are responsible for our own content on these pages under the general laws. ## Liability for links External links lead to third-party websites whose content we cannot influence; the respective provider is always responsible for that content. No legal violations were apparent when the links were set. If we become aware of any infringement, we will remove the link immediately. ## Copyright The content and works on this website are subject to copyright. Copying, editing, distribution and any kind of use beyond the limits of copyright law require the prior consent of Aloaha Limited. --- # Legal: Privacy policy URL: https://www.form-provider.com/en/privacy.html This page explains what happens with your data when you visit these information pages and when you use the eForms Server to fill in or design forms. ## Controller Aloaha Limited, “Helgoland” 45, Triq Gio Felice Inglott, Pembroke PBK1131, Malta E-mail: info@aloaha.com, phone: +49 541 3859 4554. More details in the imprint. If you use a form published by another organisation on this server, that organisation is responsible for the form data; Aloaha processes them on its behalf. ## Information pages: what we do not do - No cookies on the information pages, neither our own nor third-party. - No analytics or statistics services, no advertising or tracking pixels, no fingerprinting. - No external fonts or CDNs: fonts, styles and images are delivered by this server. ## Server logs Like every web server, this server logs technical access data: IP address, date and time, requested address, status code, amount of data, referrer and browser identification (user agent). We need these data to deliver the website and the forms securely and to fend off attacks. The legal basis is Art. 6(1)(f) GDPR (legitimate interest in secure operation). We do not use them for advertising or profiling, do not combine them with other data and do not pass them on. ## Using the form server When you log in or fill in a form, the server uses a session cookie and, after logging in, cookies that keep you signed in. They are technically necessary for these functions (Art. 6(1)(b) and (f) GDPR) and expire when you log off or the session ends. Remembered entries: so that you do not have to type everything again, your browser keeps what you enter in a form in its local storage, separately for each form, for up to 90 days. These entries stay on your device and are not sent to us. Passwords, signatures, attachments and payment details are never kept. Use "Clear" in the notice on the form, or delete the site data in your browser, to remove them. Bot protection: to keep automated spam out, the form page contains an invisible check. Your browser computes a short value in the background, and the server checks it together with the time between opening and sending the form. No personal data is used for this, no cookie is set for it and no third-party service is involved. Submitted forms: the data you enter and the attachments you add are used to create a sealed PDF and an XML file. They are sent by e-mail to you (if you entered an e-mail address) and to the business owner of the form. By default the server does not keep a copy; if the form owner has enabled the encrypted archive, a password-protected PDF is kept that can only be opened with the submission ID. Sign-in with an identity provider: if you sign in with an Aloaha or CodeB account (www.aloaha.com, phone.codeb.io or phone.aloaha.com), or a form requires sign-in, you are redirected to that provider, and we receive the identity data needed for the sign-in (such as name, e-mail address and role) and, if the form uses it, for pre-filling the form. Webhooks: if the owner of a form has set up a webhook, the submitted data (and, if chosen, the PDF) are also sent over HTTPS to a system named by the form owner, for example their CRM. Until delivery the message waits on the server; messages that cannot be delivered are deleted after 7 days at the latest. The form owner is responsible for the receiving system. Prefilled links: if you received a link that opens a form with your data already filled in, the form owner stored these values on the server to create the link. They are deleted when the link expires (by default after 7 days, at most after 90 days) or when the owner revokes it. ## Contact by e-mail or phone If you write to us or call us, we process your details (name, e-mail address, phone number, content of the request) to deal with your request. The legal basis is Art. 6(1)(b) GDPR if your request aims at a contract, otherwise Art. 6(1)(f) GDPR. We delete the data when they are no longer needed, unless statutory retention periods apply. ## Your rights You have the right of access (Art. 15 GDPR), rectification (Art. 16), erasure (Art. 17), restriction of processing (Art. 18), data portability (Art. 20) and to object to processing based on legitimate interests (Art. 21). You can withdraw consent at any time with effect for the future. An e-mail to info@aloaha.com is enough. You can also complain to a data protection supervisory authority, for example the authority responsible for us in Malta, the Information and Data Protection Commissioner (IDPC), or the authority where you live or work. ## No automated decisions We do not make automated decisions or create profiles within the meaning of Art. 22 GDPR. ## Security The website and the forms are delivered over HTTPS only. Last updated: October 2026 --- # CodeB eForms Server: Ein Formular. PDF und HTML. Signiert und zugestellt. URL: https://www.form-provider.com/de/index.html Der CodeB eForms Server ist eine webbasierte Formularplattform: Sie gestalten ein Formular einmal im Browser, der Server veröffentlicht es als ausfüllbares PDF, responsives HTML und statisches HTML. Jede Einreichung kommt als versiegeltes PDF mit maschinenlesbarem XML per E-Mail zurück. Ohne Programmierung und ohne App. Betrieb im eigenen Rechenzentrum auf Windows Server und IIS oder gehostet bei Aloaha. Früher Aloaha eForms Server, entwickelt von der Aloaha Limited in Malta. ## Kurz gesagt - Was: ein webbasierter Formularserver. Ein Entwurf im Browser wird zum ausfüllbaren PDF (AcroForm), zu responsivem HTML und statischem HTML. - Ergebnis: jede Einsendung als versiegeltes PDF (SHA-512-Serversignatur, optional Zeitstempel nach RFC 3161) mit XML-Daten, per E-Mail. - Dazu: handschriftliche und X.509-Signaturen, ZUGFeRD-/XRechnung-E-Rechnungen, Anmeldung mit der EU Digital Identity Wallet, REST-API und Webhooks. - Betrieb: im eigenen Rechenzentrum (Windows Server, IIS, .NET Framework 4.7.2) oder gehostet von der Aloaha Limited, Malta (EU). ## Was der eForms Server leistet Der CodeB eForms Server macht aus Papier- und PDF-Formularen Online-Formulare, die auf jedem Gerät funktionieren. Formulargestalter bauen das Formular in einem WYSIWYG-Editor im Browser. Bürgerinnen und Bürger, Kunden oder Mitarbeitende füllen es auf dem Smartphone, im Browser am PC oder im Adobe Reader aus. Der Server prüft die Eingaben, erzeugt das Ergebnis und sendet es an die einreichende Person und an die fachlich zuständige Stelle. Gedacht ist er für Verwaltungen, Versicherungen, Immobilien- und Rechtsbüros, Hochschulen und Unternehmen, die Formulare mit belastbarer Nachweiskette brauchen: signiert, mit Zeitstempel und lesbar für Mensch und Software. ## Das bekommen Sie Die wichtigsten Bausteine. Jeder ist auf einer eigenen Seite ausführlich beschrieben. - **Formulardesigner im Browser**: Textfelder, Kontrollkästchen, Optionsfelder, Auswahllisten, Bilder, Linien und Signaturfelder per Drag-and-drop platzieren. Schriften, Farben und Prüfregeln festlegen. - **PDF und HTML aus einem Entwurf**: Jedes freigegebene Formular gibt es als dynamisches PDF, responsives HTML und statisches HTML. Der Server wählt das passende Format für das Gerät. - **Handschriftliche und X.509-Signatur**: Mit Finger oder Maus unterschreiben, der Server versiegelt das Ergebnis. Felder namens esignature werden zu PDF-Signaturfeldern für Zertifikate und Chipkarten. - **E-Mail-Zustellung mit XML-Daten**: Die einreichende Person erhält das versiegelte PDF, die zuständige Stelle zusätzlich die Daten als XML. Mailtexte sind Vorlagen je Sprache. - **ZUGFeRD und Factur-X**: Rechnungsformulare werden zu E-Rechnungen nach EN 16931: PDF/A-3 mit eingebettetem XML, automatisch bei der Einreichung. - **Benutzer, Gruppen und Anmeldung**: Rollen für Administratoren, Gestalter und Gäste, Formulargruppen und Anmeldung mit Ihrem Aloaha- oder CodeB-Konto (OpenID Connect), auch mit Passkey und der EU Digital Identity Wallet. ## So geht ein Formular online 1. Gestalten. Neues Formular anlegen oder ein bestehendes klonen, Felder platzieren und Prüfregeln festlegen. 2. Prüfen und freigeben. PDF-Vorschau ansehen, dann freigeben. Der Server erzeugt das dynamische PDF und beide HTML-Fassungen und meldet sich per E-Mail, wenn sie fertig sind. 3. Link teilen. Den Formularlink auf die Website, in eine E-Mail oder auf einen QR-Code setzen. Kein Plug-in, keine App. 4. Einreichungen empfangen. Jede Einreichung wird als PDF versiegelt und mit den XML-Daten per E-Mail zugestellt, bereit für die Sachbearbeitung. ## Datenschutz durch Technik Der eForms Server führt keine Datenbank eingereichter Formulare. Eine Einreichung wird zu versiegeltem PDF und XML, per E-Mail zugestellt und danach vom Server entfernt. Wer eine serverseitige Kopie braucht, nutzt das optionale verschlüsselte Archiv: passwortgeschützte PDFs, die sich nur mit der Einreichungs-ID öffnen lassen. Weil der Server im eigenen Rechenzentrum laufen kann, müssen Formulardaten Ihre Infrastruktur nie verlassen. ## Eigener Formularserver oder Formular-Baukasten? Was sich zwischen dem Betrieb des CodeB eForms Server und einem typischen gehosteten Formular-Baukasten unterscheidet. Die richtige Wahl hängt von Ihren Daten, Dokumenten und Abläufen ab. | Frage | CodeB eForms Server | Typischer Formular-Baukasten | |---|---|---| | Wo liegen die Daten? | In Ihrem eigenen Rechenzentrum oder auf einem von Aloaha gehosteten Server in der EU (Malta). | In der Cloud des Anbieters. | | Was erhält der Absender? | Ein versiegeltes PDF genau des Formulars, das er ausgefüllt hat. | Meist eine Bestätigungs-E-Mail oder -Seite. | | Papier- und PDF-Layout | Das Formular behält das Layout des Papier- oder PDF-Originals, dazu eine responsive Fassung für Smartphones. | Meist ein reines Web-Layout. | | Unterschriften | Handschriftliche Unterschrift, vom Server versiegelt; X.509-Signaturfelder für Zertifikate und Chipkarten. | Oft ein Bild der Unterschrift oder ein Zusatzmodul. | | E-Rechnungen | ZUGFeRD / Factur-X und XRechnung aus einem Formular oder über die API. | Selten eingebaut. | | Identität | Anmeldung mit OpenID Connect, Passkeys und der EU Digital Identity Wallet; Vorbefüllung mit geprüften Daten. | Unterschiedlich. | | Anbindung | REST-API (OpenAPI 3.1) mit OAuth-2.0-Bearer-Tokens, signierte Webhooks, XML zu jeder Einsendung. | REST-API und Webhooks sind verbreitet. | ## Häufige Fragen ### Ist der CodeB eForms Server derselbe wie der Aloaha eForms Server? Ja. Der Aloaha eForms Server heißt seit Oktober 2026 CodeB eForms Server. Er wird weiterhin von der Aloaha Limited in Malta entwickelt. ### Was ist der CodeB eForms Server? Eine webbasierte Plattform zum Gestalten, Veröffentlichen und Verarbeiten elektronischer Formulare. Ein Entwurf wird als ausfüllbares PDF, responsives HTML und statisches HTML veröffentlicht; Einreichungen kommen als versiegeltes PDF mit XML per E-Mail. ### Brauchen Ausfüllende Adobe Reader oder eine App? Nein. Die responsive HTML-Fassung funktioniert in jedem aktuellen Browser auf Smartphone, Tablet und PC. Das dynamische PDF steht für alle bereit, die den Adobe Reader bevorzugen. ### Können Formulare unterschrieben werden? Ja. Handschriftliche Unterschriften werden mit Finger oder Maus erfasst und vom Server versiegelt. Formulare mit Anmeldepflicht können mit dem eigenen Schlüssel der Person auf dem CodeB-Server signiert werden, alle anderen erhalten das Siegel Ihrer Organisation, beides als PAdES bis B-LTA. Felder namens esignature werden zu PDF-Signaturfeldern für X.509-Zertifikate und Chipkarten. ### Wo werden eingereichte Daten gespeichert? Standardmäßig nirgends: Die Einreichung wird als versiegeltes PDF mit XML per E-Mail zugestellt und dann entfernt. Ein optionales verschlüsseltes Archiv kann passwortgeschützte Kopien aufbewahren. ### Kann ich den Server im eigenen Rechenzentrum betreiben? Ja. Er läuft auf Windows Server mit IIS und .NET Framework 4.7.2. Aloaha kann ihn auch für Sie hosten. ### Wie wird der eForms Server lizenziert? Gibt es eine Testphase? Sie nutzen den eForms Server gehostet bei Aloaha oder mieten einen Server zur Installation im eigenen Rechenzentrum; gemietete Inhouse-Server erhalten kostenlose Updates, Integrationshilfe und Online-Schulung sind kostenlos. Es gibt eine kostenlose 30-Tage-Testphase mit drei Beispielformularen. Preise auf Anfrage an info@aloaha.com. ### Kann ich E-Rechnungen ohne eigene Rechnungssoftware versenden? Ja. Gestalten Sie Ihre Rechnungsvorlage einmal auf dem eForms Server und füllen Sie sie für jede Rechnung aus; jede Einreichung wird zu einer konformen ZUGFeRD-/XRechnung-E-Rechnung (PDF/A-3 mit XML nach EN 16931) und per E-Mail versendet. ### Kann der eForms Server E-Rechnungen erzeugen? Ja. Rechnungsformulare lassen sich bei der Einreichung in ZUGFeRD / Factur-X (EN 16931) umwandeln: PDF/A-3 mit eingebettetem Rechnungs-XML. ### Ist der CodeB eForms Server ein Formular-Baukasten? Er ist ein Formularserver: Sie gestalten Formulare im Browser wie in einem Baukasten, aber jedes Formular gibt es auch als ausfüllbares PDF, jede Einsendung ist ein versiegeltes PDF mit XML, und Sie können den Server selbst betreiben. ### Hat der CodeB eForms Server eine API und Webhooks? Ja. Eine als OpenAPI 3.1 beschriebene REST-API listet Formulare und Felder, prüft, füllt und sendet Formulare und erstellt E-Rechnungen; Webhooks schicken jede Einsendung als signiertes JSON an Ihr System. ## Mit Ihren eigenen Formularen ansehen Testen Sie die öffentlichen Beispielformulare oder fragen Sie nach einer kostenlosen Online-Präsentation oder einer kostenlosen 30-Tage-Testversion. --- # Funktionsübersicht: Alle Funktionen an einem Ort. URL: https://www.form-provider.com/de/features.html Diese Seite zeigt, was der eForms Server kann, geordnet nach den Stationen eines Formulars: Gestaltung, Veröffentlichung, Ausfüllen, Zustellung, Signatur, E-Rechnung, Benutzer und Betrieb. ## Kurz gesagt - Gestalten: WYSIWYG-Editor im Browser mit Textfeldern, Kontrollkästchen, Optionsfeldern, Auswahllisten, Bildern und Signaturfeldern; Prüfung mit regulären Ausdrücken. - Veröffentlichen: dynamisches PDF, responsives und statisches HTML aus einem Entwurf; der Server wählt das Format je Gerät. - Zustellen: versiegeltes PDF an den Absender, PDF mit XML an den Business Owner; Anhänge werden PDF-Seiten oder eine ZIP-Datei. - Anbinden: Anmeldung per OpenID Connect, REST-API (OpenAPI 3.1), Webhooks, ZUGFeRD/XRechnung, im eigenen Betrieb oder gehostet. ## Formulare gestalten - WYSIWYG-Designer im Browser: keine Installation, läuft auf jedem Arbeitsplatz mit aktuellem Browser. - Feldtypen: Textfelder, mehrzeiliger Text, Kontrollkästchen, Optionsfelder, Auswahllisten, Schaltflächen, Linien, Bilder, Fließtext und Signaturfelder. - Layout: Schrift, Schriftgröße, Farben, Hintergrundfarbe, Ausrichtung, Maximallänge, Pflichtfelder. - Prüfregeln: ein regulärer Ausdruck je Feld, mit fertigen Regeln für E-Mail-Adressen und Ausweisnummern und eigenen Fehlermeldungen. - Briefköpfe und kaskadierte Dokumente: Ein Formular kann von einem Briefkopf abhängen; eine Änderung am Briefkopf wirkt auf alle abhängigen Formulare. - Vorlagen und Klonen: mit dem Vorlagen-Assistenten starten oder ein bestehendes Formular klonen. - Sicherung: Formular mit allen Einstellungen exportieren und auf demselben oder einem anderen Server wiederherstellen. ## Veröffentlichen - Drei Formate aus einem Entwurf: dynamisches PDF (AcroForm, für Adobe Reader), responsives HTML für Smartphone und Tablet sowie statisches HTML im Drucklayout. - Automatische Formatwahl: Der Server erkennt das Gerät und liefert das passende Format; Links können ein Format auch gezielt anfordern (pdf=1, web=1, static=1). - Freigabe-Ablauf: PDF-Vorschau, Freigabe, E-Mail-Benachrichtigung nach dem Rendern. - Mehrsprachig: Sprachfassungen von Formularen und allen E-Mail-Texten. ## Ausfüllen und Einreichen - Jedes Gerät: Smartphone, Tablet, Browser am PC und Adobe Reader. - Anhänge: Dokumente vor dem Absenden anfügen; Bilder werden zu PDF-Seiten, andere Dateien gezippt angehängt. Formulare können Anhänge verlangen. - Spamschutz ohne CAPTCHA: Eine unsichtbare Prüfung im Server hält Bots fern. Niemand muss Bilder anklicken oder verzerrte Buchstaben abtippen, und kein Drittanbieter wie Google reCAPTCHA sieht Ihre Besucher. - Merkt sich Ihre Eingaben: Wer dasselbe Formular erneut öffnet, findet seine früheren Eingaben aus dem eigenen Browser wieder, für jedes Formular getrennt. Auf dem Server wird nichts gespeichert, und ein Klick löscht sie. - Vorbefüllung aus geprüfter Identität: Nach der Anmeldung mit einem Aloaha- oder CodeB-Konto, etwa mit der EU Digital Identity Wallet über www.aloaha.com, lassen sich Namens- und Adressfelder automatisch füllen. - Handschriftliche Signaturfelder direkt im Formular, siehe Signaturen. ## Zustellung und Daten - Versiegeltes PDF: Jede Einreichung wird als PDF erzeugt und vom Server digital versiegelt. - Zwei E-Mails: Die einreichende Person erhält das versiegelte PDF, die zuständige Stelle zusätzlich die Formulardaten als XML zur Weiterverarbeitung. Weitere Empfänger sind konfigurierbar. - Mailvorlagen: Betreff, Text und Fußzeile je Formulargruppe und Sprache, mit Platzhaltern wie Formular-ID, Dokument-ID, Einreichungs-ID und Link. - Keine Einreichungsdatenbank: Daten werden zugestellt und entfernt. Ein optionales verschlüsseltes Archiv hält passwortgeschützte PDFs, abrufbar nur mit der Einreichungs-ID. - Zähler und Berichte: Einreichungen je Formular und Monat, als CSV-Bericht. ## Signaturen - Handschriftliche elektronische Signatur mit Finger, Stift oder Maus, durch eine SHA-512-Serversignatur an das Dokument gebunden. - Optionaler Zeitstempel eines RFC-3161-Zeitstempeldienstes, etwa des Aloaha Timestamping Server. - X.509-Signaturfelder: Textfelder namens esignature werden zu PDF-Signaturfeldern für Zertifikate und Chipkarten (fortgeschrittene und qualifizierte Signatur). ## E-Rechnung - ZUGFeRD / Factur-X: Rechnungsformulare werden bei der Einreichung zu E-Rechnungen nach EN 16931 (PDF/A-3 mit eingebettetem XML). - ZUGFeRD-Werkzeuge: XML aus einem ZUGFeRD-PDF auslesen, XML in ein vorhandenes PDF einbetten oder das PDF mit einer DOCX-Vorlage aus XML erzeugen; auch als Webservice. ## Benutzer, Gruppen und Anmeldung - Rollen: Administratoren, Benutzer (Formulargestalter) und Gäste. - Formulargruppen: Jede Gruppe sieht und verwaltet ihre eigenen Formulare; jedes Formular hat eine zuständige Stelle und einen Gestalter. - Anmeldung mit Aloaha- und CodeB-Konten: Neben lokalen Konten bietet die Anmeldeseite die Anmeldung über www.aloaha.com, phone.codeb.io und phone.aloaha.com (OpenID Connect, Authorization Code Flow mit PKCE). Die Rolle des Kontos (Administrator, Benutzer oder Gast) wird unverändert übernommen, der Server des Kontos wird zu seiner Formulargruppe. - Passkeys und EU Digital Identity Wallet: www.aloaha.com unterstützt bereits die Anmeldung mit Passwort, Passkey (FIDO2 / WebAuthn) und der kommenden European Digital Identity Wallet (eIDAS 2.0, OpenID4VP, SD-JWT VC). Weil der eForms Server sich darüber anmeldet, stehen diese Verfahren auch für den Formularserver bereit. Mehr zur EUDI-Wallet. - Anmeldung je Formular: Ein Formular kann vor dem Ausfüllen eine Anmeldung verlangen. ## Aloaha ID: eine Anmeldung für Ihre Anwendungen Hinter der Anmeldung am eForms Server steht www.aloaha.com, ein standardkonformer OpenID-Connect-Anbieter, den Aloaha betreibt. Sie können ihn auch für Ihre eigenen Anwendungen nutzen: - Standardprotokoll: OpenID Connect mit Authorization Code Flow und PKCE, signierte ID-Tokens (RS256), Userinfo, Abmeldung und Token-Widerruf. Jede OIDC-Bibliothek funktioniert; das Discovery-Dokument liegt unter www.aloaha.com/.well-known/openid-configuration. - Moderne Anmeldeverfahren: Passwort, Passkey (FIDO2 / WebAuthn), E-Mail-Link und die European Digital Identity Wallet (eIDAS 2.0, OpenID4VP, SD-JWT VC), bereit, bevor die Wallet akzeptiert werden muss. - Rollen und Gruppen: Über die Claims role und groups verwalten Sie Administrator-, Benutzer- und Gastrechte an einer Stelle. - Datenschutz: Datenvereinbarungen, Einwilligungsbelege, Zugriffsprotokoll und Löschanfragen für jeden Benutzer. Derselbe Dienst läuft auf phone.codeb.io und phone.aloaha.com. Für die Anbindung Ihrer Anwendung schreiben Sie an info@aloaha.com oder lesen die API-Dokumentation. ## Einbindung und Betrieb - Einbindung: auf ein Formular verlinken oder es in die eigene Website einbetten; der Link bestimmt das Format. - Eigenbetrieb oder gehostet: im eigenen Rechenzentrum oder auf einem von Aloaha betriebenen Server. - Voraussetzungen: Windows Server mit IIS (integrierte Pipeline) und .NET Framework 4.7.2. - Schulung und Unterstützung: kostenlose Online-Schulung und Hilfe bei der Integration; kostenlose Updates für gemietete Inhouse-Server. ## Häufige Fragen ### Welche Feldtypen unterstützt der Designer? Textfelder, mehrzeiligen Text, Kontrollkästchen, Optionsfelder, Auswahllisten, Schaltflächen, Linien, Bilder, Fließtext und Signaturfelder. ### Wie werden Eingaben geprüft? Jedes Feld kann einen regulären Ausdruck und eine Fehlermeldung erhalten. Fertige Regeln gibt es für E-Mail-Adressen und Ausweisnummern. ### Was passiert mit Anhängen? Bilder werden in PDF-Seiten umgewandelt, andere Dateien gezippt an das eingereichte PDF angehängt. ### Welche Anmeldeverfahren gibt es? Lokale Benutzerkonten und die Anmeldung mit einem Aloaha- oder CodeB-Konto über OpenID Connect: www.aloaha.com, phone.codeb.io und phone.aloaha.com. Die Rolle des Kontos (Administrator, Benutzer oder Gast) bleibt erhalten. ### Verwenden die Formulare ein CAPTCHA? Nein. Der eForms Server hat einen eigenen, unsichtbaren Bot-Schutz: Der Browser löst im Hintergrund eine kleine Rechenaufgabe, während das Formular ausgefüllt wird, und der Server prüft zusätzlich Zeitpunkt, ein verstecktes Fallenfeld und dass jedes Formular nur einmal gesendet wird. Die Menschen merken davon nichts, und kein CAPTCHA-Dienst eines Drittanbieters ist beteiligt. ### Kann man sich mit der EU Digital Identity Wallet anmelden? Ja, über www.aloaha.com. Dort wird die kommende European Digital Identity Wallet bereits akzeptiert, ebenso Passkeys; die geprüfte Anmeldung erhält der eForms Server per OpenID Connect. --- # Online-Formulardesigner: Formulare im Browser erstellen. URL: https://www.form-provider.com/de/form-designer.html Der Aloaha Online-Formulardesigner ist ein WYSIWYG-Editor: Sie platzieren Felder dort, wo sie auf der Seite hingehören, und der Server erzeugt die PDF- und HTML-Fassungen. Ohne Download, ohne Programmierung. ## Kurz gesagt - Keine Installation: der Designer läuft in jedem aktuellen Browser, am Desktop und per Touch auf Tablet und Smartphone. - Felder: ein- und mehrzeiliger Text, Kontrollkästchen, Optionsfelder, Auswahllisten, Bilder, Text, Linien, Schaltflächen, handschriftliche und X.509-Signaturfelder. - Regeln: jedes Eingabefeld kann einen regulären Ausdruck und eine Fehlermeldung haben; Pflichtfelder werden markiert. - Ergebnis: eine Freigabe erzeugt das ausfüllbare PDF und beide HTML-Fassungen des Formulars. ## Was Sie platzieren können - **Eingabefelder**: Ein- und mehrzeiliger Text, Kontrollkästchen, Optionsfelder und Auswahllisten, jeweils mit eigener Prüfregel. - **Inhalte**: Bilder, Fließtext und Linien, um jedes Papierformular nachzubauen. - **Schaltflächen und Signaturen**: Funktionsschaltflächen, handschriftliche Signaturfelder und esignature-Felder für X.509-Zertifikate. ## Der Designer in Bildern Der Editor zeigt die Seite so, wie sie gedruckt wird: Werkzeuge links, die Seite in der Mitte, das ausgewählte Feld rechts. Ein Doppelklick auf ein Feld öffnet Name, Typ, Prüfregel und Farben. Mit Preview sehen Sie das Formular genau so, wie es die Nutzer erhalten, und auf dem Smartphone funktioniert derselbe Editor mit dem Finger. Jeder Schritt steht im Editor-Handbuch. ![Der Formulardesigner des CodeB eForms Server: Werkzeuge links, die Formularseite in der Mitte, das ausgewählte Feld rechts](https://www.form-provider.com/web-assets/manual/editor-overview.png) ![Dialog Feldeigenschaften: Name, Typ, Prüfregel, Schrift und Farben eines Formularfelds](https://www.form-provider.com/web-assets/manual/editor-properties.png) ![Vorschau der Formularseite ohne Feldrahmen, wie das freigegebene PDF aussieht](https://www.form-provider.com/web-assets/manual/editor-preview.png) ![Der Formulardesigner auf dem Smartphone: die Seite, die Leiste Tools und die Leiste Field](https://www.form-provider.com/web-assets/manual/editor-mobile.png) ## Regeln, Briefköpfe und Wiederverwendung Prüfregeln: Jedes Feld kann einen regulären Ausdruck und eine Fehlermeldung tragen, etwa für E-Mail-Adressen oder Ausweisnummern. Briefköpfe: Formulare können von einem oder mehreren Dokumenten wie einem Briefkopf abhängen. Ändern Sie den Briefkopf einmal, folgen alle abhängigen Formulare; sprachspezifische Briefköpfe schalten die Formularsprache automatisch um. Wiederverwendung: bestehende Formulare klonen, mit Vorlagen starten und Formulare als Sicherung exportieren, um sie später oder auf einem anderen Server wiederherzustellen. ## Ihr erstes Formular 1. Anmelden und auf Create new form klicken. 2. Eine eindeutige Document ID, Ihre E-Mail-Adresse als Benachrichtigungsadresse und eine kurze Beschreibung eingeben. 3. Mit Create Field Objekte auf der Seite anlegen. 4. Ein Objekt auswählen und unter Field Properties den Typ wählen; Text, Werte, Bilder und Prüfregel festlegen. 5. Mit Show PDF die Vorschau des ausfüllbaren PDF ansehen. 6. Release PDF drücken. Der Server erzeugt das dynamische PDF und beide HTML-Fassungen und benachrichtigt Sie per E-Mail. ## Wer den Designer nutzt Formularverantwortliche in Verwaltung, Versicherung, Hausverwaltung, Hotellerie, Schulen und Unternehmen machen mit dem Designer aus vorhandenen Papier- oder PDF-Formularen Online-Formulare. Laden Sie das Original als Briefkopf hoch, legen Sie die Eingabefelder darüber, ergänzen Sie Prüfregeln und geben Sie das Formular frei. Weil der Designer mit Punkten auf der PDF-Seite arbeitet, sieht das freigegebene PDF genau wie das Original aus, und die responsive HTML-Fassung passt dieselben Felder an kleine Bildschirme an. Das Editor-Handbuch erklärt jedes Werkzeug Schritt für Schritt, und über die REST-API liest Ihre Software die Felder jedes freigegebenen Formulars. ## Häufige Fragen ### Muss ich zum Gestalten etwas installieren? Nein. Der Designer läuft im Browser. ### Kann ich ein bestehendes Formular wiederverwenden? Ja. Klonen Sie es aus der Formularbibliothek oder nutzen Sie einen Briefkopf, von dem viele Formulare abhängen. ### Kann ich mein vorhandenes PDF- oder Papierformular verwenden? Ja. Laden Sie das Original als Briefkopf hoch und legen Sie die Eingabefelder darüber; das freigegebene PDF behält das ursprüngliche Layout. ### Funktioniert der Designer auf Tablet und Smartphone? Ja. Der Editor arbeitet per Touch: zum Auswählen tippen, zum Verschieben ziehen, und auf kleinen Bildschirmen die Leisten unten nutzen. ### In welchen Formaten gibt es ein freigegebenes Formular? Jedes freigegebene Formular gibt es als dynamisches PDF (AcroForm), responsives HTML und statisches HTML unter einem Link. ## Den Designer ausprobieren Fragen Sie nach einer kostenlosen 30-Tage-Testversion oder vereinbaren Sie eine kostenlose Online-Präsentation. --- # Editor-Handbuch: Editor-Handbuch: von der leeren Seite zum freigegebenen Formular. URL: https://www.form-provider.com/de/editor-manual.html Dieses Handbuch führt durch den Formular-Editor des CodeB eForms Server: wo was ist, wie Sie Felder platzieren und anordnen, ihre Eigenschaften festlegen und das fertige Formular freigeben. Die Screenshots zeigen das Beispielformular „Meldeschein“. Der Editor selbst ist englisch; Schaltflächen sind hier mit ihrer englischen Beschriftung genannt. ## Kurz gesagt - Aufbau: obere Leiste mit Seitenumschalter und Freigabe, Werkzeuge links, die Seite in der Mitte, das ausgewählte Feld rechts. - Maße: Positionen und Größen in Punkt (1/72 Zoll), der PDF-Einheit. - Sicherheitsnetz: Wiederherstellungspunkte vor Löschen, Zusammenführen und Seitenänderungen; Go back kehrt zum letzten zurück. - Touch: auf dem Smartphone öffnen sich die Werkzeuge als Leisten von unten; Select several ersetzt Strg + Klick. ## Inhalt 1. Der Editor im Überblick 2. Felder hinzufügen 3. Auswählen, verschieben, Größe ändern 4. Feldeigenschaften 5. Mehrere Felder anordnen 6. Seiten 7. Rückgängig und Hausstil 8. Vorschau und PDF 9. Formular freigeben 10. Auf Smartphone und Tablet 11. Klassische Ansicht 12. Fragen und Antworten ## Der Editor im Überblick Öffnen Sie ein Formular in der Formularbibliothek mit edit, oder legen Sie mit Create new form ein neues an. Der Editor hat vier Bereiche: - Obere Leiste: Formularname und Seitenzahl sowie die Aktionen für das ganze Formular: Form library (zurück), Show PDF, Download PDF und Release form. - Werkzeuge links: Felder hinzufügen, mit den ausgewählten Feldern arbeiten, Seiten und Rückgängig. - Die Seite in der Mitte: So sieht das Formular aus. Jedes Feld steht genau dort, wo es im PDF stehen wird. - Ausgewähltes Feld rechts (Selected field): Typ, Position und Größe des angeklickten Feldes sowie kurze Tipps. Fahren Sie mit der Maus über ein Werkzeug, um zu sehen, was es tut. Für Smartphone und Tablet siehe unten. ![Der Formular-Editor: Werkzeuge links, die Seite in der Mitte, das ausgewählte Feld rechts](https://www.form-provider.com/web-assets/manual/editor-overview.png) ![Obere Leiste des Editors mit Formularname, Form library, Show PDF, Download PDF und Release form](https://www.form-provider.com/web-assets/manual/editor-topbar.png) ## Felder hinzufügen Klicken Sie oben in den Werkzeugen auf Add field. Ein neues Feld erscheint in einer Ecke der Seite; ziehen Sie es an seinen Platz. Jedes neue Feld beginnt als Textelement. Wählen Sie rechts in der Typliste, was es sein soll: - Text Field: ein Eingabefeld, das ausgefüllt wird. - Plain Text: fester Text wie Überschriften, Beschriftungen und Hinweise. - Drop Down, Check Box, Radio Button: Auswahlmöglichkeiten. - Image, Line, Button: Bilder, Linien und Schaltflächen. ### Briefpapier Upload letterhead legt ein PDF oder Bild hinter die Seite, etwa Ihr Firmenbriefpapier oder ein eingescanntes Papierformular zum Nachbauen. Remove letterhead entfernt es wieder. ![Werkzeuge links: Add field, Briefpapier, ausgewählte Felder, Ausrichten, Angleichen und gleiches Aussehen](https://www.form-provider.com/web-assets/manual/editor-tools.png) ## Auswählen, verschieben, Größe ändern - Auswählen: Feld anklicken. Es erhält einen orangefarbenen Rahmen. - Mehrere auswählen: Strg gedrückt halten und weitere Felder anklicken, oder auf einem leeren Teil der Seite ein Rechteck aufziehen. - Verschieben: Feld ziehen. - Größe ändern: am kleinen Griff unten rechts ziehen. - Genaue Werte: X, Y, Breite und Höhe rechts eintragen. Die Werte sind in Punkt (1/72 Zoll, die PDF-Einheit). X zählt vom linken Rand, Y wie im PDF vom unteren Rand der Seite. - Löschen: Delete Field rechts, Delete in den Werkzeugen oder Rechtsklick auf das Feld. Das Kästchen oben in den Werkzeugen zeigt immer, wie viele Felder ausgewählt sind. ![Zwei ausgewählte Felder mit orangefarbenem Rahmen auf der Seite](https://www.form-provider.com/web-assets/manual/editor-selection.png) ![Bereich Selected field mit Typ, X, Y, Breite und Höhe](https://www.form-provider.com/web-assets/manual/editor-inspector.png) ## Feldeigenschaften Doppelklicken Sie auf ein Feld oder klicken Sie rechts auf Field Properties, um seine Eigenschaften zu öffnen: - Name: der Feldname im PDF und in den XML-Daten, die Sie erhalten. Verwenden Sie kurze, eindeutige Namen wie Nachname. - Group ID: Felder mit derselben Gruppe gehören zusammen, etwa die Optionsfelder einer Frage. - Description: die Beschriftung für die ausfüllende Person, auch in Meldungen und in der HTML-Fassung verwendet. - Field is Required und Validation: Pflichtfeld festlegen und die Eingabe prüfen, etwa E-Mail-Adresse, Datum oder Postleitzahl. - Text: vorbelegter Text oder der Text eines Plain-Text-Elements. Toggle HTML schaltet auf formatierten Text um. - Background, Font, Größe und Farbe, Bold, Italics, Block Justify. - Multiline: erlaubt mehrere Zeilen. Text as Comb mit Max. Characters verteilt die Zeichen gleichmäßig auf Kästchen, wie auf Papierformularen. OK übernimmt, Cancel verwirft. Bilder haben einen eigenen kleinen Dialog zum Hochladen; Schaltflächen und Linien einen für Beschriftung, Farben und Aktion. ![Dialog Form Properties mit Name, Group ID, Beschreibung, Pflichtfeld, Prüfung, Text, Hintergrund, Schrift und Kammfeld](https://www.form-provider.com/web-assets/manual/editor-properties.png) ## Mehrere Felder anordnen Wählen Sie zwei oder mehr Felder aus und verwenden Sie die Werkzeuge links: - Selected fields: Copy und Paste (Tipp: Rechtsklick auf die Seite und Paste setzt die Kopien genau dort ein), Duplicate (Kopie neben dem Original), Delete, Merge into one (zu einem zusammenfassen). - Line up: linke, mittlere, rechte, obere oder untere Kanten ausrichten. - Make equal: gleiche Breite, gleiche Höhe, gleichmäßige Abstände waagerecht oder senkrecht. - Same look: gleiche Schrift, gleiche Farben, gleiche Gruppe oder die Felder als Tabelle markieren. ### Befehle kombinieren Einige Befehle haben ein kleines Kästchen daneben. Ist es angehakt, läuft dieser Befehl zusammen mit dem nächsten angeklickten Befehl. Beispiel: Same width anhaken, dann Left klicken: Die Felder erhalten in einem Schritt dieselbe Breite und werden links ausgerichtet. ## Seiten Ein Formular kann mehrere Seiten haben. Zum Blättern dient der Seitenumschalter in der oberen Leiste neben dem Formularnamen: Die Pfeile führen zur vorherigen und zur nächsten Seite, die Liste springt direkt zu einer Seite (zum Beispiel Page 2 of 3). Auf dem Smartphone zeigt er nur die Pfeile und die Nummer. Unter Pages in den Werkzeugen: - Page und Orientation: zu einer Seite springen, zwischen Hoch- und Querformat wechseln. - Previous und Next: wie die Pfeile in der oberen Leiste. - Add page, Copy page (mit allen Feldern), Delete page. Die Zeile über der Seite zeigt, wo Sie sind, zum Beispiel Page 1 of 2 · Portrait · 595 × 842 pt (A4). ![Pages sowie Undo and checks in den Werkzeugen](https://www.form-provider.com/web-assets/manual/editor-tools-pages.png) ## Rückgängig und Hausstil - Save restore point: merkt sich den aktuellen Stand des Formulars. - Go back: kehrt zum letzten Wiederherstellungspunkt zurück. Undo go back macht das rückgängig. - Apply house style: setzt linken Rand, Breite, Höhe, Schrift und Farben aller Felder nach den Stilregeln Ihres Servers, damit alle Formulare gleich aussehen. Löschen, Zusammenfassen, Seitenänderungen und der Hausstil legen vorher automatisch einen Wiederherstellungspunkt an. ## Vorschau und PDF Beim Bearbeiten haben die Felder zarte Umrisse, damit Sie sie finden. Schalten Sie über der Seite Preview ein, um alle Umrisse und Griffe auszublenden: Die Seite sieht dann aus wie das freigegebene Formular. Show PDF erzeugt das PDF und öffnet es in einem neuen Tab. Download PDF speichert es. ![Die Seite in der Vorschau: ohne Umrisse, wie das fertige PDF](https://www.form-provider.com/web-assets/manual/editor-preview.png) ## Formular freigeben Ein Formular ist erst nach der Freigabe öffentlich. Klicken Sie in der oberen Leiste auf Release form: - Form Designer eMail: Ihre Adresse; Sie erhalten Hinweise zum Formular. - Business Owner eMail: erhält jede Einsendung als versiegeltes PDF mit den Daten als XML. - Optionen für Anhänge (Pflicht, nur Bilder, Upload auf der letzten Seite), die Absenden-Schaltfläche und eine dauerhafte Weiterleitung. - Require sign-in with : Besucher melden sich zuerst bei diesem Server an; das Formular wird aus ihrem Konto vorausgefüllt. - Sign the PDF when it is submitted: Jedes eingesendete PDF wird signiert, mit dem persönlichen Schlüssel der angemeldeten Person, wenn das Formular eine Anmeldung verlangt, sonst mit dem Siegel der Organisation (Signaturen). Klicken Sie auf OK. Der Server erzeugt dann das PDF, das responsive HTML und das statische HTML des Formulars. Geben Sie das Formular nach jeder Änderung erneut frei; bis dahin sehen Besucher die vorherige Fassung. ![Dialog Release Form mit E-Mail von Designer und Geschäftsinhaber sowie Optionen](https://www.form-provider.com/web-assets/manual/editor-release.png) ## Auf Smartphone und Tablet Der Editor lässt sich auch mit den Fingern bedienen, auf Tablets und Smartphones. Auf dem Smartphone öffnen sich Werkzeuge und ausgewähltes Feld als Bereiche über die Leiste unten: Tools, Field (die Zahl zeigt, wie viele Felder ausgewählt sind), Select several und Preview. - Auswählen: Feld antippen. Erneutes Antippen hebt die Auswahl auf. - Verschieben und Größe ändern: ein ausgewähltes Feld mit dem Finger ziehen, oder am orangefarbenen Punkt in seiner Ecke die Größe ändern. Wischen an anderer Stelle scrollt die Seite, so verschieben Sie nie versehentlich ein Feld. - Genaue Position: unter Field verschieben die Pfeile das Feld um 1 pt oder 10 pt; Breite und Höhe stehen in den Feldern darüber. - Mehrere Felder: Select several einschalten und die Felder antippen. Danach wieder ausschalten. - Eigenschaften: Feld doppelt antippen, oder unter Field auf Field Properties tippen. - Zoom: die Seite erscheint in Originalgröße; mit zwei Fingern verkleinern Sie die Ansicht auf die ganze Seite. ![Der Editor auf dem Smartphone: die Seite, der Bereich Tools und der Bereich Field mit den Pfeilen zum Verschieben](https://www.form-provider.com/web-assets/manual/editor-mobile.png) ## Klassische Ansicht Das bisherige Layout des Editors gibt es weiterhin: Klicken Sie rechts in der oberen Leiste auf Classic view. Switch to the new editor (unten rechts) bringt Sie zurück. Beide bearbeiten dasselbe Formular und liefern genau dasselbe Ergebnis; der Browser merkt sich Ihre Wahl. ## Fragen und Antworten ### Zeigt der Editor das Formular genau so, wie es aussehen wird? Ja. Jedes Feld wird in seiner echten Position und Größe in Punkt, mit Schrift und Farben angezeigt. Preview blendet die Bearbeitungsumrisse aus; Show PDF zeigt das erzeugte PDF. ### Wie wähle ich mehrere Felder aus? Strg gedrückt halten und die Felder anklicken, oder auf einem leeren Teil der Seite ein Rechteck aufziehen. Das Kästchen oben in den Werkzeugen zeigt, wie viele Felder ausgewählt sind. ### Warum sind manche Werkzeuge grau? Sie wirken auf ausgewählte Felder. Wählen Sie ein oder mehrere Felder auf der Seite aus, dann werden sie aktiv. ### Warum erscheint meine Änderung nicht im öffentlichen Formular? Besucher sehen die freigegebene Fassung. Klicken Sie nach Änderungen erneut auf Release form. ### Kann ich einen Fehler rückgängig machen? Ja. Go back kehrt zum letzten Wiederherstellungspunkt zurück; Löschen, Zusammenfassen und Seitenänderungen legen automatisch einen an. Save restore point legt jederzeit einen an. ### Kann ich den Editor auf Smartphone oder Tablet verwenden? Ja. Feld antippen, um es auszuwählen, dann mit dem Finger ziehen, um es zu verschieben. Auf dem Smartphone öffnen sich Werkzeuge und Feldeinstellungen über die Leiste unten; Select several ersetzt Strg + Klick, und die Pfeile unter Field verschieben ein Feld genau. ### Wo ist der alte Editor? Klicken Sie in der oberen Leiste auf Classic view. Switch to the new editor bringt Sie zurück. ## Mit Ihren eigenen Formularen ausprobieren Fragen Sie nach einer kostenlosen Online-Präsentation oder einer kostenlosen 30-Tage-Testversion. --- # Mobile Formulare: Papierlos auf jedem Bildschirm. URL: https://www.form-provider.com/de/responsive-forms.html Papierabläufe kosten Zeit und erzeugen Fehler. CodeB eForms werden direkt auf dem vorhandenen Gerät ausgefüllt, unterschrieben und versendet, und jedes Formular gibt es als responsives HTML und als ausfüllbares PDF. ## Kurz gesagt - Drei Formate, ein Link: responsives HTML (Smartphone, Tablet), statisches HTML (Desktop, Drucklayout) und dynamisches PDF (Adobe Reader). - Automatisch: der Server erkennt das Gerät; web=1, static=1 oder pdf=1 im Link erzwingen ein Format. - Keine App: Formulare werden im vorhandenen Browser ausgefüllt, unterschrieben und gesendet. ## Warum Organisationen umsteigen - **Daten zuverlässig erfassen**: Geprüfte Eingaben statt unleserlicher Handschrift; die Daten kommen als XML. - **Nachweise vereinfachen**: Versiegelte PDFs, Signaturen und Zeitstempel dokumentieren jede Einreichung. - **Ein Erscheinungsbild**: Briefköpfe und kaskadierte Formulare halten das Corporate Design einheitlich. ## Drei Formate, ein Link Der Server wählt automatisch. Mit einem Parameter im Formularlink fordern Sie ein bestimmtes Format an. | Format | Am besten für | Link-Parameter | |---|---|---| | Responsives HTML | Smartphone und Tablet | web=1 | | Statisches HTML | Browser am PC, Drucklayout | static=1 | | Dynamisches PDF | Adobe Reader, Ausfüllen offline | pdf=1 | ## Wie das Format gewählt wird Ein Formularlink öffnet pdfforms.aspx?fid=. Der Server prüft das Gerät: Smartphones und Tablets erhalten die responsive HTML-Fassung, Desktop-Browser die statische HTML-Fassung mit Drucklayout und Adobe Reader das dynamische PDF. Mit &web=1, &static=1 oder &pdf=1 erzwingen Sie ein Format, etwa in einem QR-Code auf einem Plakat, der immer die mobile Fassung öffnen soll. Alle drei Fassungen senden an dieselbe Stelle: Das Ergebnis ist dasselbe versiegelte PDF mit denselben XML-Daten, egal welche Fassung genutzt wurde. Eingaben kann der Browser für einen späteren Besuch merken, und ein vorausgefüllter Link öffnet das Formular mit bereits eingetragenen Werten. ## Häufige Fragen ### Brauchen Ausfüllende eine App? Nein. Ein aktueller Browser genügt; der Adobe Reader ist für die PDF-Fassung optional. ### Welche Adobe-Reader-Version braucht die PDF-Fassung? Das dynamische PDF benötigt Adobe Reader XI oder neuer. Die responsive und die statische HTML-Fassung brauchen nur einen aktuellen Browser. ### Wie kommt ein Formular auf meine Website? Verlinken oder einbetten. Der Link bestimmt das Format, oder der Server wählt automatisch. ### Liefern alle drei Formate dasselbe Ergebnis? Ja. Responsives HTML, statisches HTML und das PDF senden dieselben Felder; das Ergebnis ist dasselbe versiegelte PDF mit XML-Daten. ### Kann ich jemandem ein bereits ausgefülltes Formular schicken? Ja. Die REST-API erstellt vorausgefüllte Links, die das Webformular mit vorgegebenen Werten öffnen, standardmäßig 7 Tage gültig. --- # Signaturen: Formulare auf jedem Gerät unterschreiben. URL: https://www.form-provider.com/de/signatures.html Der eForms Server unterstützt zwei Arten von Signaturen: handschriftliche elektronische Signaturen direkt im Formular und digitale X.509-Signaturen im Adobe Reader mit Zertifikat oder Chipkarte. ## Kurz gesagt - Handschriftlich: mit Finger, Stift oder Maus im Formular unterschrieben; der Server bindet die Unterschrift mit einer SHA-512-Signatur an das Dokument. - Je Formular: "Sign the PDF when it is submitted" im Freigabedialog; Formulare mit Anmeldung werden mit dem eigenen Schlüssel der Person auf dem CodeB-Server signiert, alle anderen erhalten das Siegel der Organisation. - Langzeit: Signaturen des CodeB-Signaturdienstes erreichen PAdES B-LTA: Signaturzeitstempel, Prüfdaten (Zertifikate und OCSP-Antworten) und ein Archivzeitstempel über das Dokument. - X.509: Textfelder mit dem Namen esignature werden PDF-Signaturfelder für Zertifikate und Chipkarten (fortgeschrittene und qualifizierte Signatur). ## Handschriftliche elektronische Signatur Signaturfelder werden auf Smartphone und Tablet mit Finger oder Stift, am PC mit der Maus unterschrieben. Ihre Geräte werden zum Unterschriften-Pad, ohne Hardware zu kaufen oder eine App zu installieren. - Die Unterschrift wird durch eine SHA-512-Signatur des Servers an genau ein Dokument gebunden. - Die Serversignatur kann einen Zeitstempel eines RFC-3161-Zeitstempeldienstes tragen, etwa des Aloaha Timestamping Server. - Die Kommunikation zwischen Gerät und Server ist per TLS verschlüsselt. Typische Einsätze: Unterschriften in der Filiale oder am Schalter, Außendienst vor Ort, Bestätigungen von Besichtigungen oder Lieferungen. ## Digitale X.509-Signatur Benennen Sie im Designer ein Textfeld esignature, und es wird zum PDF-Signaturfeld. Nach dem Einreichen öffnet die Person das bestätigte PDF im Adobe Reader, klickt auf das Feld und signiert mit Zertifikat oder Chipkarte. Eine Senden-Schaltfläche schickt das signierte PDF an die zuständige Stelle. ## Signaturstufen nach eIDAS Die EU-Verordnung eIDAS unterscheidet drei Stufen elektronischer Signaturen. | Stufe | Was sie ist | Mit dem eForms Server | |---|---|---| | Einfach (EES) | Jedes elektronische Zeichen einer Willenserklärung, etwa eine gezeichnete Unterschrift. | Handschriftliche Signatur, vom Server versiegelt und mit Zeitstempel. | | Fortgeschritten (FES) | Eindeutig der unterzeichnenden Person zugeordnet, erkennt spätere Änderungen. | Signatur mit dem persönlichen Schlüssel der angemeldeten Person auf einem CodeB-Server (Formulare mit Anmeldung) oder X.509-Signaturfeld mit persönlichem Zertifikat. | | Qualifiziert (QES) | Fortgeschrittene Signatur mit qualifiziertem Zertifikat auf sicherer Signaturerstellungseinheit. | X.509-Signaturfeld mit qualifizierter Chipkarte, etwa mit dem Aloaha PDF Signator. | ## Was der Server festhält Wird ein Formular mit handschriftlicher Unterschrift abgesendet, erzeugt der Server das vollständige Formular samt Unterschriftsbild als PDF und versiegelt es mit seiner eigenen digitalen Signatur (SHA-512). Jede spätere Änderung am PDF bricht das Siegel, was PDF-Programme wie Adobe Reader anzeigen. Ist ein Zeitstempelserver nach RFC 3161 eingerichtet, belegt das Siegel auch, wann unterschrieben wurde. Absender und Formularinhaber erhalten dasselbe versiegelte PDF. Für eine höhere Stufe können Formulare eine Anmeldung mit geprüfter Identität verlangen, etwa mit der EU Digital Identity Wallet, und das PDF hält fest, wie sich die Person angemeldet hat. ## Jede Einsendung versiegeln oder signieren Ob das PDF einer Einsendung signiert wird, legen Sie je Formular fest: Setzen Sie beim Freigeben das Häkchen bei Sign the PDF when it is submitted. Der Server signiert dann jedes eingesendete PDF in dieser Reihenfolge: - Formulare mit Anmeldepflicht bei einem CodeB-Server (zum Beispiel phone.codeb.io) werden mit dem persönlichen Schlüssel der angemeldeten Person auf genau diesem Server signiert. Der Server nutzt dafür die Anmeldung der Person; niemand muss Software installieren oder ein Zertifikatspasswort eingeben. - Alle anderen Formulare erhalten das Siegel der Organisation: vom CodeB-Signaturdienst mit einem eigenen Konto oder von einem Zertifikat auf dem Formularserver selbst. - Ist die persönliche Signatur nicht möglich, etwa weil der Schlüssel der Person eine PIN verlangt, erhält das PDF stattdessen das Siegel der Organisation. So geht keine Einsendung verloren. Signaturen des CodeB-Signaturdienstes sind fortgeschrittene elektronische Signaturen im PAdES-Format (nicht qualifiziert) und auf der Seite unsichtbar; PDF-Programme zeigen sie in der Signaturleiste. Standardmäßig erreichen sie die Stufe PAdES B-LTA: - B-T: Ein Zeitstempel nach RFC 3161 belegt, wann das PDF signiert wurde. - B-LT: Zertifikate und OCSP-Antworten werden eingebettet, die Signatur lässt sich also später ohne die ursprünglichen Server prüfen. - B-LTA: Ein Archivzeitstempel über das Dokument schützt Signatur und Prüfdaten. Der Signaturdienst meldet die erreichte Stufe. Ein PDF unterhalb der niedrigsten akzeptierten Stufe (eine Einstellung) erhält stattdessen das Siegel der Organisation. Formulare mit handschriftlicher Unterschrift werden immer versiegelt. ## Häufige Fragen ### Ist eine handschriftliche Unterschrift im Webformular rechtsgültig? Sie ist eine einfache elektronische Signatur nach eIDAS. Der eForms Server bindet sie mit einer Serversignatur und optionalem Zeitstempel an das Dokument, sodass spätere Änderungen erkannt werden. ### Können Formulare mit Chipkarte signiert werden? Ja. Felder namens esignature werden zu PDF-Signaturfeldern, die im Adobe Reader mit X.509-Zertifikaten und Chipkarten signiert werden können. ### Was ist der Unterschied zwischen versiegeltem und signiertem PDF? Das Siegel ist die digitale Signatur des Servers über das eingesandte Formular: Es belegt, dass das Dokument seit der Einsendung unverändert ist. Eine persönliche X.509-Signatur leistet die unterschreibende Person mit ihrem eigenen Zertifikat oder ihrer Chipkarte im Feld esignature. ### Brauche ich ein Unterschriftenpad? Nein. Smartphones und Tablets funktionieren mit Finger oder Stift, Desktops mit der Maus; Hardware oder App sind nicht nötig. ### Kann die ausfüllende Person das Formular mit ihrem eigenen Schlüssel signieren? Ja, wenn das Formular die Anmeldung bei einem CodeB-Server verlangt und beim Einsenden signiert werden soll. Das PDF wird dann mit dem persönlichen Schlüssel der angemeldeten Person auf dem Server signiert, bei dem sie sich angemeldet hat, als fortgeschrittene elektronische Signatur (PAdES, nicht qualifiziert). Geht das nicht, erhält das PDF das Siegel der Organisation. ### Kann ich festlegen, welche Formulare signiert werden? Ja. Setzen oder entfernen Sie beim Freigeben das Häkchen bei "Sign the PDF when it is submitted". Formulare mit handschriftlicher Unterschrift werden immer versiegelt. ### Lässt sich ein signiertes PDF auch in zehn Jahren noch prüfen? Eine Signatur nach PAdES B-LTA trägt ihre Prüfdaten und einen Archivzeitstempel selbst, sie lässt sich also ohne die Server prüfen, die die Zertifikate ausgestellt haben. Damit sie über die Laufzeit des Zeitstempelzertifikats hinaus prüfbar bleibt, muss vor dessen Ablauf ein neuer Archivzeitstempel ergänzt werden. ### Was passiert, wenn der Zeitstempeldienst ausfällt? Die eigene Signatur der Person wird dann ohne Zeitstempel erstellt (Stufe B-B), sofern die niedrigste akzeptierte Stufe das zulässt; sonst erhält das PDF das Siegel der Organisation. Die erreichte Stufe steht im Ereignisprotokoll des Servers. --- # EUDI-Wallet: Die EU-Identitätsbrieftasche, schon heute für Ihre Formulare. URL: https://www.form-provider.com/de/eudi-wallet.html Mit der European Digital Identity Wallet (EUDI-Wallet) weist sich jede Person in der EU per Smartphone aus und teilt geprüfte Daten. Über www.aloaha.com nimmt der CodeB eForms Server sie bereits an: Man meldet sich mit der Wallet an, und das Formular wird mit geprüften Daten vorausgefüllt. Bis Ende 2026 muss jeder EU-Mitgliedstaat eine Wallet anbieten, bis Ende 2027 müssen Banken, Telekommunikationsanbieter, Versorger, Gesundheitsdienste und große Online-Plattformen sie akzeptieren. Sie können schon jetzt bereit sein. ## Kurz gesagt - Heute: Formulare auf dem CodeB eForms Server akzeptieren die EU Digital Identity Wallet über den Anmeldedienst www.aloaha.com. - Standards: OpenID4VP mit DCQL, SD-JWT-VC- und ISO-mdoc-Nachweise, HAIP-Profil des EU Architecture and Reference Framework. - Fristen: Wallets in jedem EU-Mitgliedstaat bis Ende 2026; Akzeptanz durch regulierte private Dienste bis Ende 2027 (eIDAS 2.0, Verordnung (EU) 2024/1183). - Eigene App: CodeB Wallet für Android verwahrt PID, Führerschein und Mitgliedskarten, zeigt sie per OpenID4VP oder ISO/IEC 18013-5 vor, prüft Ausweise, liest Pass-Chips und signiert PDFs (AdES; QES mit qualifizierter Karte wie der maltesischen eID, im Test). Geschlossene Beta; keine offizielle staatliche Wallet, nicht zertifiziert. ## Was ist die EUDI-Wallet? Die European Digital Identity Wallet, auf Deutsch EU-Brieftasche für die Digitale Identität, ist eine App, die jeder EU-Mitgliedstaat seinen Bürgerinnen und Bürgern sowie Einwohnern bereitstellt, für die private Nutzung kostenlos. Sie enthält die staatlich ausgestellten Personenidentifizierungsdaten (PID: Name, Geburtsdatum, Staatsangehörigkeit, Anschrift) und kann weitere Nachweise aufnehmen, etwa Führerschein, Zeugnisse, Berufsqualifikationen oder einen Altersnachweis. Rechtsgrundlage ist eIDAS 2.0, die Verordnung (EU) 2024/1183 zur Änderung der eIDAS-Verordnung (EU) Nr. 910/2014, in Kraft seit dem 20. Mai 2024. Die technischen Regeln stehen im Architecture and Reference Framework (ARF) der EU und in den Durchführungsrechtsakten. - Die Person entscheidet: Die Wallet zeigt, welche Daten ein Dienst anfragt; ohne Zustimmung wird nichts übermittelt. - Nur das Nötige: Dank selektiver Offenlegung erhält ein Formular zum Beispiel Name und Anschrift, aber nichts weiter. - An der Quelle geprüft: Die Daten sind von der ausstellenden Stelle signiert, sie können weder vertippt noch gefälscht werden. - EU-weit anerkannt: Eine Wallet aus einem Mitgliedstaat funktioniert bei Diensten in allen anderen. ## Die wichtigsten Termine Der Zeitplan von eIDAS 2.0 für Wallets und die Dienste, die sie annehmen. | Wann | Was passiert | |---|---| | 20. Mai 2024 | eIDAS 2.0, Verordnung (EU) 2024/1183, tritt in Kraft. | | Ende 2026 | Jeder EU-Mitgliedstaat muss mindestens eine zertifizierte EUDI-Wallet anbieten, einschließlich kostenloser qualifizierter elektronischer Signaturen für private Zwecke. Deutschland hat seine staatliche Wallet für Anfang 2027 angekündigt. | | Ende 2027 | Private Dienste, die Nutzer gesetzlich stark identifizieren müssen, etwa Banken, Zahlungsdienste, Telekommunikation, Energieversorger, Verkehr, Gesundheitswesen und Bildung, sowie sehr große Online-Plattformen müssen die Wallet akzeptieren, wenn die Nutzer sie verwenden wollen. | ## Warum das für Formulare wichtig ist Fast jedes Formular beginnt mit denselben Fragen: Wer sind Sie, wann sind Sie geboren, wo wohnen Sie? Heute tippen Menschen diese Daten immer wieder ab, machen Fehler, und die Organisation hinter dem Formular hat keinen Nachweis, dass sie stimmen. Die Wallet ändert das. - Schneller ausgefüllt: Eine Bestätigung in der Wallet füllt Name, Geburtsdatum und Anschrift. - Weniger Fehler und Betrug: Die Daten kommen signiert von der ausstellenden Stelle, statt abgetippt zu werden. - Datensparsamkeit nach DSGVO: Das Formular erhält nur die angefragten Daten, und die Person sieht und bestätigt sie. - Keine Konten zu verwalten: Niemand braucht für Ihre Formulare noch ein weiteres Passwort. - Vor der Frist bereit: Wenn Sie die Wallet ab Ende 2027 akzeptieren müssen, können Ihre Formulare es schon. ## So unterstützt Aloaha die Wallet heute Zwei Teile arbeiten zusammen: der Anmeldedienst www.aloaha.com und der eForms Server. - **www.aloaha.com nimmt die Wallet an**: Der Anmeldedienst von Aloaha prüft Wallet-Nachweise mit OpenID for Verifiable Presentations (OpenID4VP) und DCQL-Abfragen, für SD-JWT VC und ISO mdoc, nach dem High Assurance Interoperability Profile (HAIP) des ARF. - **Eine Anmeldung per OpenID Connect**: Anwendungen binden www.aloaha.com mit Standard-OpenID-Connect an. Sie erhalten die geprüften Daten wie bei jeder Anmeldung, ganz ohne eigenen Wallet-Code. - **Formulare mit Anmeldepflicht**: Legen Sie ein Formular in die Gruppe des Anmeldeservers und setzen Sie „Anmeldung erforderlich“. Jeder Besucher meldet sich zuerst an, mit Wallet, Passkey oder Passwort. - **Mit geprüften Daten vorausgefüllt**: Name, Geburtsdatum und Anschrift, die die Person aus der Wallet freigibt, landen direkt in den passenden Formularfeldern. Das eingereichte PDF hält fest, wie sich die Person angemeldet hat. - **Auch mit Passkey und Passwort**: Wer noch keine Wallet hat, meldet sich mit Passkey (FIDO2 / WebAuthn) oder Passwort an. Sie brauchen keine zwei Systeme. - **Betrieb in der EU**: Die Aloaha Limited hat ihren Sitz in Malta. Den eForms Server können Sie im eigenen Rechenzentrum betreiben, sodass Formulardaten Ihre Infrastruktur nie verlassen. ## CodeB Wallet: unsere eigene EUDI-Wallet-App für Android Neben der Annahme der staatlichen Wallets entwickelt Aloaha eine eigene Wallet-App: CodeB Wallet für Android, ausgelegt auf eIDAS 2.0 (Verordnung (EU) 2024/1183) und das EU Architecture and Reference Framework. Sie bewahrt Ausweis, Führerschein und Mitgliedskarten auf dem Telefon auf, zeigt sie vor Ort oder online vor, prüft die Ausweise anderer und signiert PDFs. CodeB Wallet ist in einer geschlossenen Beta auf Google Play für eingeladene Tester; die öffentliche Veröffentlichung und eine iPhone-Version sind angekündigt. Die App gibt es auf Deutsch, Englisch und Maltesisch. Sie ist keine offizielle staatliche Wallet und nicht zertifiziert. Ihr Browser kann dieses Video nicht abspielen. Teaser herunterladen (MP4, 2 MB) CodeB Wallet in 32 Sekunden: Karte hinzufügen, nur teilen, was nötig ist, PDF signieren, Ausweis oder nur das Alter prüfen. Das Video hat keinen Ton. Auch auf YouTube: Deutsch, Englisch. - Dokumente: Personenidentifizierungsdaten (PID, auch eine deutsche PID), der mobile Führerschein (SD-JWT VC und ISO/IEC 18013-5 mdoc) und eine CodeB-Mitgliedskarte, per OpenID4VCI vom CodeB-Aussteller (phone.codeb.io) oder über den QR-Code eines anderen Ausstellers. Die EU-Referenzaussteller sind ebenfalls wählbar; Aussteller werden gegen ETSI-Vertrauenslisten geprüft. Demnächst: ein Lichtbildausweis (Photo ID, ISO/IEC TS 23220-4), auf Wunsch mit den Chipdaten des Passes als ICAO Digital Travel Credential, nur mit Zustimmung der Inhaberin oder des Inhabers. - PDFs mit dem CodeB-Signaturdienst signieren: fortgeschrittene elektronische Signaturen (AdES) als PAdES B-T mit vertrauenswürdigem Zeitstempel, mit derselben PDF-Technik von Aloaha wie im eForms Server (Signaturen). Das Dokument bleibt auf dem Telefon, jede Signatur wird bestätigt. Das sind keine qualifizierten Signaturen. Ein PDF, das jemand anderes schickt, lässt sich über den QR-Code von phone.codeb.io/sign-request signieren. - Mit der eigenen Signaturkarte signieren (im Test): das Telefon ist das NFC-Kartenlesegerät, ein Computer oder USB-Leser ist nicht nötig. Die maltesische eID-Karte und maltesische Aufenthaltskarten mit Signaturzertifikat erzeugen eine qualifizierte elektronische Signatur (QES), weil die Karte ein qualifiziertes Zertifikat trägt; die CAN öffnet die verschlüsselte PACE-Verbindung, die Signatur-PIN geht nur an die Karte, und der Schlüssel verlässt den Chip nie. Außerdem: D-Trust Card 5.1 (QES) und 5.4 (qualifiziertes Siegel), der Heilberufsausweis HBA G2.1 (QES) und die Gesundheitskarte eGK G2.1 (fortgeschrittene Signatur). Die App zeigt, ob das Kartenzertifikat eine qualifizierte Signatur ausweist; laut myeuid.app wurde die QES mit echten maltesischen eID- und D-Trust-Karten vollständig getestet. Die Qualifizierung kommt von der Karte, nicht von der App: CodeB Wallet selbst ist nicht zertifiziert. - Pässe und Ausweise lesen (im Test): die App liest den Chip elektronischer Pässe und Ausweise nach ICAO Doc 9303 (Name, Geburtsdatum, Staatsangehörigkeit, Dokumentnummer, Ablaufdatum, Foto) mit der CAN oder der per Kamera gescannten MRZ, prüft die Signatur des ausstellenden Staates gegen die CSCA-Masterlisten und erkennt geklonte Chips. Für eine PID kann der CodeB-PID-Anbieter den Chip über das Telefon auf einem Ende-zu-Ende geschützten Kanal lesen (PACE, Chip Authentication, Secure Messaging); das Telefon leitet die Nachrichten nur weiter, die echte App wird mit Android Key Attestation und Play Integrity geprüft. - Kostenloses CodeB-Konto (im Test): in der App angelegt, indem man den Chip von Pass oder Ausweis scannt und einen E-Mail-Code bestätigt. Es erlaubt fünf signierte PDFs pro Tag sowie die Test-PID und die Photo ID. Es ist ein dokumentgeprüftes Gastkonto, keine offizielle Identität und keine qualifizierte Signatur; CAN, MRZ und Chip-Rohdaten werden nicht gespeichert. - Ausweise vorzeigen und prüfen: vor Ort mit ISO/IEC 18013-5, gestartet per QR-Code oder NFC, Daten über Bluetooth Low Energy, auch offline; online mit OpenID for Verifiable Presentations (OpenID4VP), dem Standard, den www.aloaha.com für Ihre Formulare prüft. Selektive Offenlegung teilt nur, was nötig ist, zum Beispiel „über 18“ statt des Geburtsdatums. Im Prüfmodus prüft dieselbe App den Ausweis einer anderen Person samt Widerruf, zeigt ein klares Ergebnis und löscht die Daten, wenn das Ergebnis geschlossen wird. - Datenschutz und Sicherheit: Schlüssel in der sicheren Hardware des Telefons, PIN und optional Biometrie, jedes Teilen und jede Signatur wird bestätigt. Dokumente und Verlauf bleiben auf dem Telefon, ohne CodeB-Cloud und ohne Werbung, Tracking oder Analyse. Status und Erneuerung werden automatisch geprüft, wo der Aussteller das unterstützt, und ein lokaler Verlauf zeigt, wer ein Dokument gesehen hat. Die App funktioniert mit TalkBack, großer Schrift und reduzierten Animationen. - White Label: Aussteller, Banken, Behörden, Verbände und Unternehmen können die Wallet unter eigenem Namen, Logo, Farben und Store-Eintrag anbieten, mit eigenen Ausstellern und Diensten (ebenfalls nicht zertifiziert). Mehr auf myeuid.app: Anleitung, Signieren mit der maltesischen eID, D-Trust-Karten, HBA und eGK, kostenloses Konto und Änderungen. Tester und White-Label-Anfragen: info@aloaha.com. ## CodeB Wallet auf einen Blick Was die App kann, welche Standards dahinterstehen und welchen Stand myeuid.app nennt (geprüft am 16. Oktober 2026). Die ganze App ist in einer geschlossenen Beta. | Funktion | Standards | Stand | |---|---|---| | Digitaler Ausweis (PID), mobiler Führerschein, Mitgliedskarte | OpenID4VCI, SD-JWT VC, ISO mdoc, ETSI-Vertrauenslisten | Für Tester verfügbar | | Photo ID mit Digital Travel Credential | ISO/IEC TS 23220-4, ICAO DTC Typ 1 | Demnächst | | Ausweis vor Ort vorzeigen | ISO/IEC 18013-5 (QR, NFC, Bluetooth LE), offline | Für Tester verfügbar | | Ausweis online vorzeigen | OpenID4VP, selektive Offenlegung | Für Tester verfügbar | | Ausweis oder Alter einer anderen Person prüfen | ISO/IEC 18013-5 als Leser, Widerrufsprüfung | Für Tester verfügbar; Rücken-an-Rücken-Prüfung im Test | | Pässe und Ausweise lesen | ICAO Doc 9303 (PACE, BAC, Chip-, Active und Passive Authentication) | Im Test | | PDF-Signatur mit dem CodeB-Signaturdienst | PAdES B-T (ETSI EN 319 142), fortgeschrittene elektronische Signatur | Im Test | | PDF-Signatur mit Signaturkarte | NFC, ISO/IEC 7816-4/-8, PACE (BSI TR-03110), ETSI EN 319 412-5; QES mit qualifizierter Karte wie der maltesischen eID | Im Test; QES mit echten maltesischen eID- und D-Trust-Karten getestet | | Identitätsprüfung beim CodeB-PID-Anbieter | ETSI TS 119 461 v2.1.1 (daran ausgerichtet, nicht zertifiziert) | Im Test | | Zertifizierung | - | Nicht zertifiziert, keine offizielle staatliche Wallet | ## So funktioniert es im Formular 1. Formular veröffentlichen. Im Designer das Formular der Gruppe des Anmeldeservers zuordnen (zum Beispiel www.aloaha.com) und bei der Freigabe Anmeldung erforderlich ankreuzen. 2. Link öffnen. Der Besucher öffnet das Formular und wird zu www.aloaha.com geleitet. 3. In der Wallet bestätigen. Der Besucher wählt die EU-Identitätsbrieftasche, scannt den QR-Code oder bestätigt auf demselben Smartphone und gibt die angefragten Daten frei. 4. Vorausgefülltes Formular prüfen. Zurück im Formular sind Name, Geburtsdatum und Anschrift bereits eingetragen. Der Besucher ergänzt den Rest und unterschreibt. 5. Absenden. Der Server versiegelt das PDF und stellt es mit den XML-Daten per E-Mail zu, wie bei jeder eForms-Einreichung. ## Typische Einsatzfälle - Öffentliche Verwaltung: Anträge und Anmeldungen, die eine geprüfte Identität brauchen. - Banken, Versicherungen und Versorger: Kundenaufnahme und Adressänderungen mit gesetzlich geforderter starker Identifizierung. - Hotels und Ferienwohnungen: Gästeanmeldung mit geprüftem Namen, Geburtsdatum und Anschrift, etwa der Meldeschein. - Gesundheit und Pflege: Einwilligungen, bei denen klar sein muss, wer unterschrieben hat. - Bildung: Einschreibung mit geprüfter Identität und künftig Zeugnissen aus der Wallet. ## Häufige Fragen ### Was ist die EUDI-Wallet? Eine App, die jeder EU-Mitgliedstaat nach eIDAS 2.0, Verordnung (EU) 2024/1183, bereitstellt. Sie enthält die staatlich ausgestellten Personenidentifizierungsdaten und weitere Nachweise und gibt ausgewählte Daten mit Zustimmung der Person an Online-Dienste weiter. ### Ab wann gibt es die EUDI-Wallet? Jeder EU-Mitgliedstaat muss bis Ende 2026 mindestens eine zertifizierte Wallet anbieten. Einige Länder haben mit Pilotprojekten früher begonnen; Deutschland hat seine staatliche Wallet für Anfang 2027 angekündigt. ### Wer muss die EUDI-Wallet akzeptieren, und ab wann? Öffentliche Stellen mit Online-Identifizierung und ab Ende 2027 private Dienste, die Nutzer gesetzlich stark identifizieren müssen, etwa Banken, Telekommunikation, Energieversorger, Verkehr und Gesundheitswesen, sowie sehr große Online-Plattformen, wenn die Nutzer die Wallet verwenden wollen. ### Unterstützt der CodeB eForms Server die EUDI-Wallet? Ja. Der eForms Server meldet Personen über www.aloaha.com an, und www.aloaha.com akzeptiert die EU-Identitätsbrieftasche. Formulare können diese Anmeldung verlangen und werden dann mit den freigegebenen, geprüften Daten vorausgefüllt. ### Welche Wallet-Standards unterstützt www.aloaha.com? OpenID for Verifiable Presentations (OpenID4VP) mit DCQL-Abfragen, SD-JWT VC und ISO mdoc, nach dem High Assurance Interoperability Profile und dem Architecture and Reference Framework der EU. Anwendungen binden sich per Standard-OpenID-Connect an. ### Welche Daten erhält ein Formular aus der Wallet? Nur die Daten, die das Formular anfragt und die Person in der Wallet freigibt, meist Name, Geburtsdatum und Anschrift. Ohne Zustimmung wird nichts übermittelt. ### Können Personen ohne Wallet das Formular trotzdem ausfüllen? Ja. Sie melden sich bei www.aloaha.com mit Passkey oder Passwort an, oder das Formular wird ohne Anmeldepflicht veröffentlicht. ### Ist die EUDI-Wallet eine qualifizierte elektronische Signatur? Nicht dasselbe, aber sie enthält eine: Wallet-Inhaber können für private Zwecke kostenlos qualifiziert elektronisch signieren. Der eForms Server unterstützt außerdem X.509-Signaturfelder für Zertifikate und Chipkarten. ### Hat Aloaha eine eigene EUDI-Wallet-App? Ja. CodeB Wallet für Android (myeuid.app) verwahrt einen digitalen Ausweis (PID), den mobilen Führerschein und eine Mitgliedskarte, zeigt sie per OpenID4VP oder ISO/IEC 18013-5 vor, prüft andere Ausweise, liest den Chip von Pässen und Ausweisen und signiert PDFs. Die App ist in einer geschlossenen Beta auf Google Play für eingeladene Tester, auf Deutsch, Englisch und Maltesisch verfügbar und weder eine offizielle staatliche Wallet noch zertifiziert. ### Kann CodeB Wallet eine qualifizierte elektronische Signatur (QES) erzeugen? Ja, mit einer qualifizierten Signaturkarte, im Test: die maltesische eID-Karte (und maltesische Aufenthaltskarten mit Signaturzertifikat), D-Trust Card 5.1 und der HBA G2.1 erzeugen per NFC eine QES, weil die Karte ein qualifiziertes Zertifikat trägt und der Schlüssel den Chip nie verlässt. Die App zeigt, ob das Kartenzertifikat qualifiziert ist. Signaturen des CodeB-Signaturdienstes sind fortgeschrittene Signaturen (AdES, PAdES B-T), keine QES. CodeB Wallet selbst ist nicht zertifiziert. ### Kann CodeB Wallet Pässe und Ausweise lesen? Ja, im Test. Die App liest den Chip elektronischer Pässe und Ausweise nach ICAO Doc 9303 mit der CAN oder der maschinenlesbaren Zone, prüft die Signatur des ausstellenden Staates gegen die CSCA-Masterlisten und erkennt geklonte Chips. Ältere Ausweise ohne Chip können nicht gelesen werden. ### Gibt es CodeB Wallet für das iPhone? Noch nicht. CodeB Wallet läuft auf Android mit NFC; eine iPhone-Version ist auf myeuid.app angekündigt. ### Können Organisationen CodeB Wallet unter eigener Marke anbieten? Ja. Aloaha bietet CodeB Wallet als White-Label-App mit eigenem Namen, Logo, Farben, Store-Eintrag, Ausstellern und Diensten an. Auch die White-Label-Wallet ist nicht zertifiziert. Kontakt: info@aloaha.com. ## Machen Sie Ihre Formulare bereit für die Wallet Fragen Sie nach einer kostenlosen Online-Präsentation oder der Anbindung Ihrer Anwendung an www.aloaha.com. --- # E-Rechnung: Rechnungsformulare, die zu E-Rechnungen werden. URL: https://www.form-provider.com/de/zugferd.html Mit dem eForms Server lässt sich ein Rechnungsformular auf jedem Gerät ausfüllen und wird bei der Einreichung zur ZUGFeRD- / Factur-X-E-Rechnung: ein PDF/A-3 für Menschen mit eingebettetem XML für die Software. ## Kurz gesagt - Format: ZUGFeRD / Factur-X ist ein PDF/A-3 mit den Rechnungsdaten als eingebettetem XML nach EN 16931. - XRechnung: das eingebettete CII-XML trägt die Kennung XRechnung 3.0 und die Käuferreferenz (Leitweg-ID). - So geht es: Rechnungsformular im Browser ausfüllen oder JSON an POST /api/v1/einvoices senden; die E-Rechnung entsteht beim Absenden. ## E-Rechnungen ohne eigene Rechnungssoftware Viele kleine Unternehmen, Vereine und Selbstständige schreiben nur wenige Rechnungen im Monat und brauchen dafür keine eigene Rechnungssoftware, doch Kunden und öffentliche Auftraggeber verlangen zunehmend E-Rechnungen. Mit dem eForms Server gestalten Sie Ihre Rechnungsvorlage einmal im Browser, mit Firmendaten, Briefkopf und Positionen, und füllen sie dann für jede Rechnung aus. Beim Absenden erzeugt der Server eine konforme E-Rechnung: ein ZUGFeRD-/Factur-X-PDF/A-3 mit eingebettetem XML nach EN 16931 im XRechnung-3.0-Format, per E-Mail an Sie und Ihren Kunden. - Keine Installation: läuft im Browser auf PC, Tablet und Smartphone. - Eigenes Layout: Briefkopf, Logo und Felder nach Ihren Wünschen; das XML entsteht aus den Feldnamen. - Bereit für öffentliche Auftraggeber: Käuferreferenz (Leitweg-ID), Fälligkeit, IBAN und Steuerkategorien einschließlich 0 % (steuerfrei, Reverse Charge, Ausfuhr). ## ZUGFeRD in Kürze ZUGFeRD ist das hybride E-Rechnungsformat des Forums elektronische Rechnung Deutschland (FeRD). Seit ZUGFeRD 2.1 ist es technisch identisch mit dem französischen Factur-X 1.0 und erfüllt die europäische Norm EN 16931. Die strukturierten Rechnungsdaten stecken als XML in einer PDF/A-3-Datei; die Rechnung ist so für Menschen lesbar und beim Empfänger vollautomatisch verarbeitbar. ## Was der eForms Server mit ZUGFeRD macht - **XRechnung 3.0**: Das eingebettete CII-XML trägt die Kennung XRechnung 3.0, inklusive Käuferreferenz (Leitweg-ID), Fälligkeitsdatum, Lieferdatum und IBAN, wenn das Formular danach fragt. - **Bei Einreichung erzeugen**: Rechnungsdaten aus dem Formular werden zu ZUGFeRD / Factur-X: PDF/A-3 mit eingebettetem XML. - **Auslesen und einbetten**: XML aus einem ZUGFeRD-PDF lesen oder XML in ein vorhandenes PDF einbetten. - **PDF aus XML**: Aus Rechnungs-XML mit einer DOCX-Vorlage ein lesbares PDF/A-3 erzeugen; auch als Webservice. ## Ausprobieren: die ZUGFeRD-Testrechnung Füllen Sie auf diesem Server eine Testrechnung aus und erhalten Sie eine ZUGFeRD- / XRechnung-E-Rechnung per E-Mail: ein PDF/A-3 mit eingebettetem XML nach EN 16931. Bitte nur Testdaten verwenden. ## Sie brauchen ein SDK? Für eigene Anwendungen in .NET, COM oder auf der Kommandozeile bietet Aloaha das ZUGFeRD Pro SDK. ## Häufige Fragen ### Ist ZUGFeRD dasselbe wie Factur-X? Technisch ja: ZUGFeRD 2.1 und Factur-X 1.0 sind identisch, beide folgen EN 16931. ### Welcher Norm folgen die erzeugten Rechnungen? EN 16931 (und CEN/TR 16931-4), als PDF/A-3 mit eingebettetem XML. ### Sind die Rechnungen gültige XRechnungen? Ja. Das XML ist in CII-Syntax mit der Kennung XRechnung 3.0 geschrieben. Testrechnungen des Formularservers bestehen die Prüfungen auf PDF/A-3b, EN 16931 und XRechnung des Mustang-Validators. Für öffentliche Auftraggeber in Deutschland tragen Sie die Leitweg-ID als Käuferreferenz ein. ### Brauche ich Rechnungssoftware, um E-Rechnungen zu senden? Nein. Gestalten Sie ein Rechnungsformular einmal, füllen Sie es für jede Rechnung aus, und der Server sendet beim Absenden eine ZUGFeRD-/XRechnung-E-Rechnung. ### Kann meine Software E-Rechnungen automatisch erstellen? Ja. POST /api/v1/einvoices nimmt die Rechnung als JSON und liefert das E-Rechnungs-PDF/A-3; siehe die Seite zur E-Rechnungs-API. --- # API: REST-API: Formulare und E-Rechnungen aus Ihrer eigenen Software. URL: https://www.form-provider.com/de/api.html Jedes Formular des Servers lässt sich aus anderen Anwendungen nutzen: Formulare auflisten, Felder lesen, Daten prüfen, ein ausgefülltes PDF erhalten, absenden oder aus strukturierten Daten eine ZUGFeRD- / XRechnung-E-Rechnung erstellen. Die API ist als OpenAPI 3.1 beschrieben und mit Bearer-Tokens Ihrer OpenID-Connect-Server geschützt. Eine Einsendung über die API wird genau wie eine aus dem Webformular verarbeitet: versiegeltes PDF, optionale Serversignatur, E-Mails, E-Rechnung. ## Kurz gesagt - Standard: REST mit JSON, beschrieben als OpenAPI 3.1 unter /api/v1/openapi; Fehler als RFC-9457-Problem-Details. - Sicherheit: OAuth-2.0-Bearer-Tokens Ihrer OpenID-Connect-Server; Rollen aus dem Token; Anfragegrenzen in jeder Antwort. - Endpunkte: Formulare, Felder, JSON Schema, prüfen, ausfüllen, absenden, E-Rechnungen, vorausgefüllte Links, Webhooks und Nutzung. ## Inhalt 1. Auf einen Blick 2. Anmeldung 3. Ein Bearer-Token erhalten 4. Endpunkte 5. Formulare und Felder lesen 6. Ausfüllen und absenden 7. E-Rechnungen (ZUGFeRD / XRechnung) 8. Webhooks 9. Vorausgefüllte Links 10. Nutzung und Anfragegrenzen 11. Fehler und Grenzen 12. Was die API abdeckt 13. Fragen und Antworten ## Auf einen Blick - Basis-URL: https:///api/v1 (auf Servern ohne URLs ohne Dateiendung: /api.ashx/v1). - Beschreibung: OpenAPI 3.1 unter /api/v1/openapi auf jedem Server und als Download. Importieren Sie sie in Postman, Swagger UI oder einen Codegenerator. - Format: JSON (UTF-8). PDFs kommen als Base64 in der JSON-Antwort oder mit Accept: application/pdf als Datei. - Fehler: Problem Details nach RFC 9457 (application/problem+json). ## Anmeldung Jeder Aufruf außer /, /health, /openapi und /field-types braucht ein Access Token eines der OpenID-Connect-Server, die auf dem Formularserver eingerichtet sind (standardmäßig phone.codeb.io, www.aloaha.com und phone.aloaha.com): Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6… - JWT-Tokens werden lokal geprüft: RS256-Signatur gegen die veröffentlichten Schlüssel des Servers, Aussteller, Ablauf und Zielgruppe (Audience). Die Audience ist die Client-ID des Formularservers; ein Administrator kann weitere Client-IDs zulassen (Einstellungen, REST-API). - Undurchsichtige Tokens werden per Token-Introspection beim ausstellenden Server geprüft. Sind mehrere Server eingerichtet, nennen Sie ihn im Header X-OIDC-Issuer: phone.codeb.io. - Rollen kommen aus dem Claim role des Tokens, wie bei der Anmeldung im Designer: admin und user sehen die Formulare ihrer Gruppe (Hostname des Anmeldeservers), guest nur freigegebene Formulare. Absenden erfordert user oder admin, außer der Administrator lässt Gäste zu. - GET /api/v1/me zeigt, für welchen Benutzer, welche Rolle und Gruppe ein Token steht. ## Ein Bearer-Token erhalten Die API nimmt die Access Tokens an, die die OpenID-Connect-Server bei der Anmeldung ausstellen (RS256-JWTs, eine Stunde gültig). Ihre Anwendung erhält eines mit dem Standardverfahren Authorization Code Flow mit PKCE; das kann jede OAuth-2.0- / OpenID-Connect-Bibliothek. Unten steht phone.codeb.io für den Anmeldeserver, den Sie verwenden. ### 1. Anwendung einmalig registrieren - Registrieren Sie Ihre Anwendung beim Anmeldeserver als OIDC-Client (das erledigt ein Administrator des CodeB-Servers unter /oidc-clients.html, oder fragen Sie uns unter info@aloaha.com). Sie wählen eine Client-ID (z. B. my-app) und die Redirect-URI, zu der die Anmeldung zurückkehrt (z. B. http://localhost:8765/callback für ein Skript). Die Redirect-URI muss Zeichen für Zeichen übereinstimmen. Mit Client-Secret ist der Client vertraulich, ohne ist er öffentlich und nutzt nur PKCE. - Auf dem Formularserver lässt ein Administrator die Client-ID zu: Settings → REST API → Other applications allowed. Tokens für die eigene Client-ID des Formularservers werden ohnehin angenommen. ### 2. Anmelden und Code erhalten Erzeugen Sie ein PKCE-Paar und öffnen Sie die Autorisierungs-URL im Browser. Die Person meldet sich an (Passwort, Passkey oder EU Digital Identity Wallet), und der Browser kehrt mit ?code=… zu Ihrer Redirect-URI zurück. VERIFIER=$(openssl rand -base64 48 | tr -d '=+/' | cut -c1-64) CHALLENGE=$(printf '%s' "$VERIFIER" | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '=') # diese URL im Browser öffnen (eine Zeile) https://phone.codeb.io/oauth2/v1/authorize?response_type=code&client_id=my-app &redirect_uri=http%3A%2F%2Flocalhost%3A8765%2Fcallback&scope=openid%20profile%20email &state=xyz&nonce=abc&code_challenge=$CHALLENGE&code_challenge_method=S256 Auch wenn unter der Redirect-URI nichts antwortet, steht der Code in der Adresszeile des Browsers. Er gilt wenige Minuten und nur einmal. ### 3. Code gegen Tokens tauschen curl -X POST https://phone.codeb.io/oauth2/v1/token \ -d grant_type=authorization_code -d client_id=my-app \ -d redirect_uri=http://localhost:8765/callback \ -d code=$CODE -d code_verifier=$VERIFIER # vertraulicher Client: zusätzlich -d client_secret=$SECRET { "access_token": "eyJhbGciOiJSUzI1NiIs…", "token_type": "Bearer", "expires_in": 3600, "id_token": "eyJ…", "refresh_token": "…" } ### 4. API aufrufen, bei Bedarf erneuern curl -H "Authorization: Bearer $ACCESS_TOKEN" https://forms.example.com/api/v1/me # nach einer Stunde: neue Tokens mit dem Refresh Token (es wechselt bei jeder Nutzung) curl -X POST https://phone.codeb.io/oauth2/v1/token \ -d grant_type=refresh_token -d client_id=my-app -d refresh_token=$REFRESH_TOKEN Das Token handelt für die angemeldete Person: Ihre role bestimmt, welche Formulare die API zeigt (siehe oben). Für einen Hintergrundjob melden Sie sich einmal mit einem eigenen Konto an und halten das Token mit dem Refresh Token aktuell. ### Der ganze Ablauf als Skript Python 3, nur Standardbibliothek: öffnet den Browser, empfängt den Code auf localhost und gibt das Access Token aus. import base64, hashlib, http.server, json, secrets, urllib.parse, urllib.request, webbrowser ISSUER, CLIENT_ID = "https://phone.codeb.io", "my-app" REDIRECT = "http://localhost:8765/callback" verifier = secrets.token_urlsafe(48) challenge = base64.urlsafe_b64encode(hashlib.sha256(verifier.encode()).digest()).rstrip(b"=").decode() state = secrets.token_urlsafe(16) webbrowser.open(ISSUER + "/oauth2/v1/authorize?" + urllib.parse.urlencode({ "response_type": "code", "client_id": CLIENT_ID, "redirect_uri": REDIRECT, "scope": "openid profile email", "state": state, "nonce": secrets.token_urlsafe(16), "code_challenge": challenge, "code_challenge_method": "S256"})) class Callback(http.server.BaseHTTPRequestHandler): def do_GET(self): q = urllib.parse.parse_qs(urllib.parse.urlparse(self.path).query) assert q.get("state") == [state], "state mismatch" self.server.code = q["code"][0] self.send_response(200); self.end_headers(); self.wfile.write(b"Angemeldet. Sie koennen diesen Tab schliessen.") def log_message(self, *a): pass srv = http.server.HTTPServer(("localhost", 8765), Callback) srv.handle_request() body = urllib.parse.urlencode({"grant_type": "authorization_code", "client_id": CLIENT_ID, "redirect_uri": REDIRECT, "code": srv.code, "code_verifier": verifier}).encode() tokens = json.load(urllib.request.urlopen(ISSUER + "/oauth2/v1/token", body)) print(tokens["access_token"]) ## Endpunkte Alle Pfade relativ zu /api/v1. | Methode | Pfad | Was er tut | |---|---|---| | GET | /forms | Formulare, die das Token nutzen darf; Filter ?released=true und ?q=. | | GET | /forms/{formId} | Einstellungen, Seitenzahl, Links zur PDF- und HTML-Fassung. | | GET | /forms/{formId}/fields | Alle Felder: Typ, Name zum Absenden, Position, Pflicht, Prüfregel, Auswahlwerte. | | GET | /forms/{formId}/schema | JSON Schema der Werte, für Codegeneratoren und KI-Agenten. | | GET | /forms/{formId}/pdf | Das leere freigegebene PDF-Formular. | | POST | /forms/{formId}/validate | Prüft Werte, ohne abzusenden. | | POST | /forms/{formId}/fill | Ausgefülltes PDF ohne Einsendung, ohne E-Mails (wie Speichern im Webformular). | | POST | /forms/{formId}/submissions | Sendet das Formular ab: versiegeltes PDF, E-Mails, E-Rechnung. | | POST | /einvoices | ZUGFeRD- / Factur-X- / XRechnung-Rechnung aus strukturierten Daten. | | POST | /forms/{formId}/prefill | Link zum Webformular mit eingetragenen Werten (DELETE /forms/{formId}/prefill/{prefillId} widerruft ihn). | | GET / POST | /forms/{formId}/webhooks | Webhooks eines Formulars auflisten oder anlegen; PATCH, DELETE, /test und /rotate-secret je Webhook (Details). | | GET | /usage | Anfragegrenze, API-Einsendungen heute, Webhook-Warteschlange. | | GET | /field-types, /validation-rules, /me | Feldtypen, Prüfregeln, Identität des Tokens. | ## Formulare und Felder lesen Listen Sie die freigegebenen Formulare auf und lesen Sie dann die Felder eines Formulars. Jedes Eingabefeld hat einen submitName: Das ist der Schlüssel beim Absenden. Optionsfelder teilen sich den Namen ihrer Gruppe; Auswahllisten nennen ihre options. curl -H "Authorization: Bearer $TOKEN" https://forms.example.com/api/v1/forms?released=true curl -H "Authorization: Bearer $TOKEN" https://forms.example.com/api/v1/forms/zugferd/fields?inputOnly=true Feldtypen: textfield, dropdown, checkbox und radio nehmen Werte auf; text, image, line und button dienen nur dem Layout. Positionen sind in Punkt angegeben, gemessen wie im Editor. ## Ausfüllen und absenden Senden Sie die Werte als Objekt aus submitName und Wert. Kontrollkästchen nehmen true oder false, Auswahllisten und Optionsgruppen einen ihrer Werte. Der Server prüft zuerst Pflichtfelder, Auswahlwerte, Länge und Prüfregeln; ist etwas falsch, antwortet er mit 422 und einer Fehlerliste und sendet nichts ab. curl -X POST https://forms.example.com/api/v1/forms/contactrequest/submissions \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"values": {"Name": "Erika Muster", "Email": "erika@example.com", "Message": "Bitte rufen Sie mich zurück.", "Consent": true}}' Antwort (201): { "submissionId": "0b6c1f2e9d4a4c51a3f0d2b7e8c91a44", "formId": "contactrequest", "status": "submitted", "pdf": { "fileName": "contactrequest.pdf", "size": 84211, "sha256": "…", "eInvoice": false, "data": "JVBERi0xLjc…" } } - /fill liefert nur das ausgefüllte PDF: nichts wird versiegelt, keine E-Mail verschickt, Pflichtfelder dürfen leer bleiben. - Formulare mit Anmeldepflicht erhalten die geprüfte Identität des Tokens, genau wie nach einer Anmeldung im Browser. Andere Formulare erhalten sie mit "useIdentity": true. - Unbekannte Feldnamen werden abgelehnt, damit Tippfehler nicht verloren gehen. Mit "ignoreUnknownFields": true werden sie stattdessen übersprungen. Weggelassene Felder behalten ihren Vorgabewert, wie im Browser. - Absenden erfordert die Rolle user oder admin; außerdem begrenzt der Server die Zahl der API-Einsendungen pro Tag. ## E-Rechnungen (ZUGFeRD / XRechnung) POST /einvoices nimmt eine Rechnung als strukturierte Daten, füllt das Rechnungsformular des Servers aus und sendet es ab. Die Antwort ist ein PDF/A-3 mit eingebettetem XML nach EN 16931 (ZUGFeRD / Factur-X; mit Käuferreferenz (Leitweg-ID) für XRechnung). Zeilensummen, Umsatzsteuer und Gesamtbetrag werden berechnet, wenn Sie sie weglassen. Datumsangaben im ISO-Format (2026-10-11), Beträge mit Punkt. curl -X POST https://forms.example.com/api/v1/einvoices \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "Accept: application/pdf" \ -o rechnung-2026-0042.pdf -d '{ "invoice": { "number": "2026-0042", "date": "2026-10-11", "currency": "EUR", "dueDate": "2026-10-25", "taxPercent": 19 }, "seller": { "name": "Example Supplies GmbH", "street": "Musterstraße 1", "postCode": "10115", "town": "Berlin", "country": "DE", "email": "billing@example.com", "vatId": "DE123456789" }, "buyer": { "name": "Example Hotel AG", "street": "Seestraße 1", "postCode": "12345", "town": "Musterstadt", "country": "DE", "email": "accounts@example.com" }, "payment": { "iban": "DE02120300000000202051", "bic": "BYLADEM1001" }, "items": [ { "name": "Beratung (Stunden)", "quantity": 4, "netPrice": 120 }, { "name": "Reisekostenpauschale", "netPrice": 80 } ] }' "action": "preview" liefert die ausgefüllte Rechnung, ohne sie zu versenden. Die Rechnung geht per E-Mail an die Adressen in den Daten, wie beim Rechnungs-Webformular. Vollständige Referenz der E-Rechnungs-API: jedes Feld mit seinem Geschäftsbegriff nach EN 16931, Rechen- und Steuerregeln, Checkliste XRechnung und Fehler. ## Webhooks Ein Webhook schickt jede Einsendung eines Formulars als JSON an Ihren HTTPS-Endpunkt, auf Wunsch mit dem versiegelten PDF, wenige Sekunden nach dem Absenden. Die Nachrichten sind mit HMAC-SHA256 nach Standard Webhooks signiert (Header webhook-id, webhook-timestamp, webhook-signature) und werden 21 Stunden lang wiederholt. Webhooks verwalten erfordert die Rolle admin. curl -X POST https://forms.example.com/api/v1/forms/contact/webhooks \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"url": "https://crm.example.com/hooks/eforms", "includePdf": true}' # Antwort 201 mit "secret": "whsec_…" (nur einmal angezeigt) Webhooks im Detail: Nachrichtenformat, Signaturprüfung in Node.js, Python, C# und PHP, Wiederholungen und Sicherheit. ## Vorausgefüllte Links Ein vorausgefüllter Link öffnet das Webformular mit bereits eingetragenen Werten, etwa einen Vertrag mit Kundennummer und Anschrift, den der Kunde nur noch prüft und unterschreibt. Die Werte bleiben auf dem Server; der Link trägt ein zufälliges Token, das nur für dieses Formular gilt und abläuft (standardmäßig nach 7 Tagen, höchstens 90). curl -X POST https://forms.example.com/api/v1/forms/contract/prefill \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"values": {"CustomerNo": "K-1042", "Surname": "Muster", "Email": "erika@example.com"}, "expiresInHours": 72, "lock": true}' { "id": "pf_1c9e…", "formId": "contract", "url": "https://forms.example.com/pdfforms.aspx?fid=contract&web=1&prefill=Qm9x…", "expiresAt": "2026-10-15T09:30:00Z", "lock": true, "fields": 3 } - Die Werte werden wie bei einer Einsendung geprüft (Optionen, Länge, Regeln), Felder dürfen aber leer bleiben. "lock": true macht die vorausgefüllten Textfelder im Browser schreibgeschützt (eine Hilfe gegen Tippfehler, keine Sicherheitsfunktion). Die Werte dürfen zusammen höchstens 64 KB groß sein. - Vom Browser gemerkte Eingaben überschreiben einen vorausgefüllten Link nicht. Verlangt das Formular eine Anmeldung, bleibt der Link über die Anmeldung erhalten. - Schicken Sie den Link nur an die Person, für die er gedacht ist: Wer ihn hat, sieht die Werte. DELETE /forms/{formId}/prefill/{id} widerruft ihn. - Links anlegen erfordert immer die Rolle user oder admin. ## Nutzung und Anfragegrenzen Jede angemeldete Antwort nennt die Grenze des Aufrufers: X-RateLimit-Limit (Anfragen pro Minute), X-RateLimit-Remaining und X-RateLimit-Reset (Sekunden bis zum neuen Zeitfenster). GET /usage liefert dasselbe, dazu (für user und admin) die heutigen API-Einsendungen gegenüber der Tagesgrenze und (für Administratoren) die Webhook-Warteschlange. curl -H "Authorization: Bearer $TOKEN" https://forms.example.com/api/v1/usage { "user": "erika@example.com", "role": "admin", "rateLimit": { "limitPerMinute": 120, "remaining": 117, "resetSeconds": 42 }, "apiSubmissions": { "today": 12, "limitPerDay": 1000, "remaining": 988, "resetsAt": "2026-10-13T00:00:00Z" }, "webhooks": { "enabled": true, "queued": 0, "failedLast7Days": 0 } } ## Fehler und Grenzen Jeder Fehler ist ein Problem-Details-Objekt mit type, title, status und detail; Prüffehler enthalten zusätzlich eine Liste der Felder. | Status | Code | Bedeutung | |---|---|---| | 400 | invalid_json | Der Inhalt ist kein JSON-Objekt. | | 401 | invalid_token, invalid_request | Token fehlt, ist abgelaufen, für eine andere Anwendung ausgestellt oder von einem unbekannten Server. | | 403 | insufficient_scope, local_account | Erforderlicher Scope fehlt oder der Name gehört zu einem lokalen Konto. | | 404 | form_not_found | Unbekanntes Formular oder Formular einer anderen Gruppe. | | 409 | form_not_released | Das Formular ist noch nicht freigegeben. | | 422 | validation_failed | Werte fehlen oder sind ungültig; siehe errors. | | 403 | role_required | Absenden und vorausgefüllte Links erfordern die Rolle user oder admin, Webhooks die Rolle admin. | | 403 | webhooks_disabled, prefill_disabled | Webhooks oder vorausgefüllte Links sind auf diesem Server abgeschaltet. | | 409 | too_many_webhooks | Das Formular hat bereits die Höchstzahl an Webhooks (standardmäßig 10). | | 404 | not_found | Unbekannter API-Pfad. | | 405 | method_not_allowed | Falsche HTTP-Methode für diesen Pfad. Wo PATCH oder DELETE nicht durchkommen, POST mit dem Header X-HTTP-Method-Override senden. | | 413 / 415 | too_large, unsupported_media_type | Inhalt größer als 10 MB oder kein JSON. | | 422 | not_an_invoice_form, too_many_items | Das gewählte Formular hat keine Rechnungspositionen oder weniger als die Rechnung. | | 429 | rate_limited, daily_limit | Zu viele Anfragen (standardmäßig 120 pro Minute und Benutzer) oder Tagesgrenze der API-Einsendungen erreicht; Retry-After abwarten. | | 502 | form_processing_failed | Das Formular konnte nicht verarbeitet werden (z. B. Mailserver nicht erreichbar). | | 500 | server_error | Fehler auf dem Server; Details stehen im Serverprotokoll. | | 503 | storage_busy | Die Webhook-Einstellungen werden gerade von einer anderen Anfrage geschrieben; bitte erneut versuchen. | | 503 | api_disabled, issuer_unavailable, loopback_not_configured | API abgeschaltet, Anmeldeserver nicht erreichbar oder interne Adresse des Servers nicht eingestellt. | ## Was die API abdeckt Wir haben die API mit den Schnittstellen verbreiteter Formular-Baukästen und PDF-Dienste verglichen. Diese bieten typischerweise: Formulare und ihre Fragen auflisten, Einsendungen lesen und anlegen, Webhooks bei neuen Einsendungen sowie PDF-Formulardaten füllen oder auslesen. Die API des CodeB eForms Server deckt ab: - Formulare und Felder, mit Feldtypen, Positionen, Prüfregeln und einem JSON Schema je Formular. - Einsendungen mit der vollständigen Verarbeitung des Webformulars: versiegeltes und optional signiertes PDF, E-Mails und Regeln für Anhänge. - PDF ausfüllen ohne Einsendung sowie das leere PDF-Formular. - E-Rechnungen (ZUGFeRD / Factur-X / XRechnung) aus strukturierten Daten, was Formular-Baukästen meist nicht können. - Sicherheit nach Standard: OAuth-2.0-Bearer-Tokens Ihrer eigenen OpenID-Connect-Server, keine zusätzlichen API-Schlüssel. - Webhooks für jede Einsendung, signiert nach Standard Webhooks, mit Wiederholungen und Fehler-E-Mails. - Vorausgefüllte Links, die ein Formular mit eingetragenen Werten öffnen, und ein Nutzungs-Endpunkt mit Headern zur Anfragegrenze. Der Server speichert eingesandte Daten bewusst nicht, daher gibt es keinen Endpunkt, der frühere Einsendungen auflistet; mit einem Webhook erhalten Sie jede Einsendung in Ihrem eigenen System. ## Fragen und Antworten ### Wie erhalte ich ein Token für die API? Melden Sie sich mit dem Authorization-Code-Flow (mit PKCE) bei einem der OpenID-Connect-Server an, die auf dem Formularserver eingerichtet sind, zum Beispiel phone.codeb.io, und verwenden Sie das Access Token. Tokens für die Client-ID des Formularservers werden angenommen; ein Administrator kann die Client-IDs weiterer Anwendungen zulassen. ### Gibt es eine OpenAPI- oder Swagger-Beschreibung? Ja. Jeder Server veröffentlicht OpenAPI 3.1 unter /api/v1/openapi, und Sie können sie auf dieser Seite herunterladen. Importieren Sie sie in Postman, Swagger UI oder einen Codegenerator. ### Kann ich über die API ZUGFeRD- oder XRechnung-Rechnungen erstellen? Ja. POST /api/v1/einvoices nimmt Verkäufer, Käufer, Positionen und Umsatzsteuer als JSON und liefert ein PDF/A-3 mit eingebettetem XML nach EN 16931. Mit Käuferreferenz (Leitweg-ID) erfüllt es XRechnung. ### Unterscheidet sich eine Einsendung über die API von einer im Browser? Nein. Die API übergibt die Werte an dieselbe Verarbeitung wie das Webformular; versiegeltes PDF, Signatur, E-Mails und E-Rechnung sind gleich. ### Kann ich eingesandte Formulare auflisten? Nein. Der Server speichert eingesandte Daten nicht; das Ergebnis geht an die eingerichteten Empfänger und an den Aufrufer zurück. Um Einsendungen in Ihrem eigenen System zu sammeln, richten Sie einen Webhook ein: Jede Einsendung geht dann als signiertes JSON an Ihren Endpunkt. ### Unterstützt die API Webhooks? Ja. POST /api/v1/forms/{formId}/webhooks trägt einen HTTPS-Endpunkt ein, der jede Einsendung des Formulars als JSON erhält, signiert mit HMAC-SHA256 nach Standard Webhooks und 21 Stunden lang wiederholt. Nachrichtenformat und Signaturprüfung stehen auf der Webhook-Seite. ### Kann ich jemandem ein bereits ausgefülltes Formular schicken? Ja. POST /api/v1/forms/{formId}/prefill liefert einen Link, der das Webformular mit Ihren Werten öffnet. Der Link gilt nur für dieses Formular und läuft standardmäßig nach 7 Tagen ab. ## Die API ausprobieren Fragen Sie nach Testzugangsdaten für unseren Online-Formularserver und testen Sie die API mit Ihren eigenen Formularen. --- # E-Rechnungs-API: E-Rechnungs-API: ZUGFeRD und XRechnung aus JSON. URL: https://www.form-provider.com/de/einvoice-api.html Ein API-Aufruf macht aus strukturierten Rechnungsdaten eine rechtskonforme elektronische Rechnung: ein PDF/A-3, das Menschen wie jedes PDF lesen, mit den Rechnungsdaten als eingebettetem XML nach EN 16931 (ZUGFeRD / Factur-X). Mit Käuferreferenz (Leitweg-ID) erfüllt die Rechnung die XRechnung-Regeln für deutsche öffentliche Auftraggeber. Der Endpunkt füllt das Rechnungsformular Ihres Servers aus und sendet es ab: Die Rechnung wird versiegelt, auf Wunsch signiert und per E-Mail versandt wie eine im Browser erfasste Rechnung. ## Kurz gesagt - Ein Aufruf: POST /api/v1/einvoices mit Verkäufer, Käufer, Positionen und Steuer als JSON. - Ergebnis: ein ZUGFeRD-/Factur-X-PDF/A-3 mit XML nach EN 16931; mit Käuferreferenz (Leitweg-ID) für XRechnung. - Berechnet: Positionssummen, Steuer und Gesamtbetrag, wenn Sie sie weglassen; "action": "preview" liefert die Rechnung, ohne sie zu senden. ## Inhalt 1. So funktioniert es 2. Kleinste Anfrage 3. Vollständiges Beispiel (XRechnung) 4. Feldreferenz 5. Beträge, Umsatzsteuer und Rundung 6. Zahlung 7. Checkliste XRechnung 8. Die Antwort 9. Eigenes Rechnungsformular 10. Grenzen und Fehler 11. Fragen und Antworten ## So funktioniert es - Ihre Software sendet POST /api/v1/einvoices mit einem Bearer-Token (siehe Ein Bearer-Token erhalten) und der Rechnung als JSON. - Der Server prüft die Daten, berechnet fehlende Summen und ordnet jeden Wert den Feldern seines Rechnungsformulars zu (standardmäßig das Formular zugferd). - Das Formular wird über die normale Formularverarbeitung abgesendet. Sie erzeugt das XML nach EN 16931 (Cross Industry Invoice, ZUGFeRD- / Factur-X-Profil EN 16931, geschrieben nach den KoSIT-Regeln der XRechnung), bettet es in ein PDF/A-3 ein und versiegelt das PDF. - Das PDF geht an Ihre Software zurück (als Base64 im JSON oder mit Accept: application/pdf als Datei) und, wie beim Webformular, per E-Mail an den Geschäftsinhaber des Formulars und an die E-Mail-Adressen in der Rechnung (Verkäufer und Käufer). "action": "preview" endet nach Schritt 2: Sie erhalten das ausgefüllte Rechnungsformular als PDF, nichts wird versiegelt oder versandt. Damit prüfen Sie Layout und Zuordnung. ## Kleinste Anfrage Rechnungsnummer, Verkäufer, Käufer und mindestens eine Position sind Pflicht. Das Rechnungsdatum ist standardmäßig heute, die Währung die Vorgabe des Formulars (EUR beim Beispielformular), alle Summen werden berechnet. curl -X POST https://forms.example.com/api/v1/einvoices \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "Accept: application/pdf" \ -o rechnung.pdf -d '{ "invoice": { "number": "2026-0042", "taxPercent": 19 }, "seller": { "name": "Example Supplies GmbH", "street": "Musterstraße 1", "postCode": "10115", "town": "Berlin", "country": "DE", "vatId": "DE123456789" }, "buyer": { "name": "Example Hotel AG", "street": "Seestraße 1", "postCode": "12345", "town": "Musterstadt", "country": "DE" }, "items": [ { "name": "Beratung (Stunden)", "quantity": 4, "netPrice": 120 } ] }' ## Vollständiges Beispiel (XRechnung) Eine Rechnung an eine deutsche Behörde mit Leitweg-ID, Kontaktdaten, Lieferdatum und SEPA-Zahlung. Datumsangaben nach ISO 8601 (yyyy-MM-dd; dd.MM.yyyy wird auch angenommen), Beträge als Zahlen mit Punkt als Dezimaltrennzeichen. { "action": "submit", "invoice": { "number": "2026-0042", "date": "2026-10-11", "currency": "EUR", "dueDate": "2026-10-25", "deliveryDate": "2026-10-09", "paymentTerms": "14 Tage netto", "buyerReference": "04011000-12345-34", "buyerOrderReference": "PO-7781", "taxPercent": 19, "taxCategory": "S", "note": "Vielen Dank für Ihren Auftrag." }, "seller": { "name": "Example Supplies GmbH", "contactName": "Erika Muster", "street": "Musterstraße 1", "postCode": "10115", "town": "Berlin", "country": "DE", "phone": "+49 30 1234567", "email": "billing@example.com", "vatId": "DE123456789" }, "buyer": { "name": "Stadt Musterstadt", "contactName": "Max Beispiel", "street": "Rathausplatz 1", "postCode": "12345", "town": "Musterstadt", "country": "DE", "email": "rechnungen@example.org" }, "payment": { "iban": "DE02120300000000202051", "bic": "BYLADEM1001", "accountName": "Example Supplies GmbH" }, "items": [ { "name": "Beratung (Stunden)", "quantity": 4, "netPrice": 120, "sellerAssignedId": "C-100" }, { "name": "Reisekostenpauschale", "netPrice": 80 } ] } ## Feldreferenz Jedes JSON-Feld, der Geschäftsbegriff (BT) nach EN 16931, den es füllt, und der Feldname im Rechnungsformular. Pflichtfelder sind markiert. | JSON | Bedeutung | EN 16931 | Formularfeld | |---|---|---|---| | invoice.number Pflicht | Rechnungsnummer | BT-1 | InvoiceID | | invoice.date | Rechnungsdatum (Standard: heute) | BT-2 | date | | invoice.currency | Währung nach ISO 4217 (EUR, CHF, …) | BT-5 | InvoiceCurrencyCode | | invoice.dueDate | Fälligkeitsdatum | BT-9 | DueDate | | invoice.buyerReference | Käuferreferenz; bei XRechnung die Leitweg-ID | BT-10 | BuyerReference | | invoice.buyerOrderReference | Bestellnummer des Käufers | BT-13 | BuyerOrderReference | | invoice.paymentTerms | Zahlungsbedingungen als Text | BT-20 | PaymentTerms | | invoice.note | Rechnungshinweis | BT-22 | InvoiceNote | | invoice.deliveryDate | Tatsächliches Lieferdatum | BT-72 | DeliveryDate | | invoice.paymentReference | Verwendungszweck (nur wenn das Formular das Feld hat) | BT-83 | PaymentReference | | invoice.taxPercent | Umsatzsteuersatz in Prozent für die ganze Rechnung | BT-152 / BT-119 | TAXPercent | | invoice.taxCategory | Steuerkategorie: S, Z, E, AE oder G (siehe unten) | BT-151 / BT-118 | TaxCategory | | invoice.taxExemptionReason | Befreiungsgrund bei E, AE, G | BT-120 | TaxExemptionReason | | seller.name Pflicht | Name des Verkäufers | BT-27 | SellerName | | seller.street, street2 | Adresszeilen | BT-35, BT-36 | SellerStreet1, SellerStreet2 | | seller.postCode, town, country | PLZ, Ort, Land (ISO 3166-1, z. B. DE) | BT-38, BT-37, BT-40 | SellerPostCode, SellerTown, SellerCountry | | seller.vatId | Umsatzsteuer-Identifikationsnummer | BT-31 | SellerVAT | | seller.contactName, phone | Ansprechpartner und Telefon | BT-41, BT-42 | SellerPersonName, SellerPhone | | seller.email | E-Mail des Verkäufers als elektronische Adresse | BT-34 | SellerEmail | | buyer.name Pflicht | Name des Käufers | BT-44 | BuyerName | | buyer.street, street2, postCode, town, country | Adresse des Käufers | BT-50 bis BT-55 | BuyerStreet1 … BuyerCountry | | buyer.vatId | USt-IdNr. des Käufers | BT-48 | BuyerVAT | | buyer.contactName, phone | Ansprechpartner beim Käufer | BT-56, BT-57 | BuyerPersonName, BuyerPhone | | buyer.email | E-Mail des Käufers als elektronische Adresse | BT-49 | BuyerEmail | | payment.iban, bic, accountName | Bankverbindung für die SEPA-Überweisung | BT-84, BT-86, BT-85 | IBAN, BIC, AccountName | | items[].name Pflicht | Artikelbezeichnung | BT-153 | ItemName1, ItemName2, … | | items[].quantity | Menge (Standard 1, Einheit C62 = Stück) | BT-129 | BilledQuantity1, … | | items[].netPrice Pflicht | Nettoeinzelpreis | BT-146 | NetPriceProductTradePrice1, … | | items[].lineTotal | Nettobetrag der Position (Standard: Menge × Preis) | BT-131 | LineTotalAmount1, … | | items[].sellerAssignedId | Artikelnummer des Verkäufers (nur wenn das Formular das Feld hat) | BT-155 | SellerAssignedID1, … | | totals.lineTotal, taxTotal, grandTotal | Summen; werden berechnet, wenn sie fehlen | BT-106, BT-110, BT-112 | LineTotalAmount, TaxTotalAmount, GrandTotalAmount | ## Beträge, Umsatzsteuer und Rundung - Positionsbetrag = Menge × Nettopreis, auf 2 Nachkommastellen gerundet (kaufmännisch), außer Sie senden lineTotal. - Summe der Positionen = Summe der Positionsbeträge; sie ist zugleich Bemessungsgrundlage und Gesamtbetrag ohne Umsatzsteuer. - Umsatzsteuer = Summe der Positionen × taxPercent / 100, auf 2 Stellen gerundet. Gesamtbetrag = Summe + Umsatzsteuer; der Zahlbetrag entspricht dem Gesamtbetrag. - Summen, die Sie in totals senden, haben Vorrang vor der Berechnung; so übernehmen Sie die exakten Zahlen Ihrer Buchhaltung. - Ein Steuersatz gilt für die ganze Rechnung. Bei mehreren Steuersätzen senden Sie je Satz eine Rechnung oder fragen Sie uns nach dem ZUGFeRD Pro SDK. - Zahlen: 1234.5 oder "1234.50". Ein Komma wird abgelehnt, so wird aus "12,50" nie 1250. ### Steuerkategorien - S Normalsatz (Standard). Mit Satz 0 wird daraus Z. - Z Nullsatz. - E steuerbefreit; ohne taxExemptionReason wird „Steuerfreie Leistung“ eingetragen. - AE Umkehr der Steuerschuld (Code VATEX-EU-AE); Standardgrund „Steuerschuldnerschaft des Leistungsempfängers“. - G Ausfuhr außerhalb der EU (VATEX-EU-G). Bei E, AE und G ist der Steuersatz 0. ## Zahlung Mit iban enthält die Rechnung eine SEPA-Überweisung (Zahlungsart 58) mit BIC und Kontoinhaber. Ohne IBAN ist die Zahlungsart „nicht angegeben“ (Code 1). Zahlungsbedingungen (paymentTerms) und Fälligkeit (dueDate) werden in jedem Fall geschrieben; ohne Fälligkeitsdatum gilt das Rechnungsdatum. ## Checkliste XRechnung Rechnungen an deutsche öffentliche Auftraggeber müssen der XRechnung entsprechen. Senden Sie mindestens: - invoice.buyerReference = die Leitweg-ID der Behörde (ohne sie schreibt der Server eine erzeugte Referenz, die eine Behörde ablehnt). - seller.email und buyer.email (elektronische Adressen), seller.contactName, seller.phone. - seller.vatId, vollständige Adressen mit Ländercodes, invoice.dueDate oder paymentTerms. - Zahlungsdaten (payment.iban), wenn die Behörde überweist. Das XML wird nach den KoSIT-Regeln geschrieben. Prüfen Sie Ihre ersten Rechnungen einmal mit dem KoSIT-Validator oder einem Viewer Ihrer Wahl. ## Die Antwort 201 Created mit der Einsendungs-ID, dem PDF und den verwendeten Summen: HTTP/1.1 201 Created { "submissionId": "7f3c2a9e0d5b4e1fa2c8b6d4e9f01a23", "formId": "zugferd", "action": "submit", "status": "submitted", "pdf": { "fileName": "zugferd.pdf", "contentType": "application/pdf", "size": 152331, "sha256": "…", "eInvoice": true, "data": "JVBERi0xLjc…" }, "totals": { "lineTotal": 560.00, "taxTotal": 106.40, "grandTotal": 666.40, "currency": "EUR" }, "notOnForm": [ "PaymentReference", "SellerAssignedID1", "SellerAssignedID2" ] } - pdf.eInvoice ist true, wenn das E-Rechnungs-XML im PDF eingebettet ist. - notOnForm nennt Werte, für die das gewählte Formular kein Feld hat (sie sind nicht Teil der Rechnung). - Mit Accept: application/pdf (oder "returnPdf": "binary") ist die Antwort das PDF selbst; der Header X-Submission-Id enthält die ID. "returnPdf": "none" lässt die PDF-Daten weg. - "action": "preview" antwortet mit 200 und der ausgefüllten, nicht versandten Rechnung. ## Eigenes Rechnungsformular Standardmäßig nutzt der Server sein Rechnungsformular (Einstellung Form for e-invoices, Vorgabe zugferd). Mit "formId" wählen Sie ein anderes, zum Beispiel eines mit Ihrem Briefkopf. Das Formular muss freigegeben sein und Felder mit den Namen aus der Feldreferenz haben; Positionen werden ab 1 (oder ab 0) nummeriert. Die Zahl der ItemName…-Felder ist die Höchstzahl der Positionen: Das Beispielformular hat 8. Gestalten Sie das Formular im Editor, benennen Sie die Felder wie aufgeführt, geben Sie es frei und prüfen Sie die Zuordnung mit "action": "preview". GET /api/v1/forms/{formId}/fields zeigt die Feldnamen eines Formulars. ## Grenzen und Fehler Fehler kommen als Problem Details (application/problem+json); siehe auch die Fehlerliste der API. | Status | Code | Bedeutung | |---|---|---| | 422 | validation_failed | Ein Pflichtwert fehlt (Nummer, Name von Verkäufer oder Käufer, Bezeichnung oder Preis einer Position), ein Datum oder eine Zahl ist nicht lesbar, oder ein Wert passt nicht zum Formular (z. B. unbekannte Währung oder Land in einer Auswahlliste). | | 422 | too_many_items | Mehr Positionen, als das Formular aufnehmen kann. | | 422 | not_an_invoice_form | Das gewählte Formular hat keine Positionsfelder. | | 403 | role_required | Rechnungen erstellen erfordert die Rolle user oder admin. | | 404 / 409 | form_not_found, form_not_released | Das Rechnungsformular gibt es für dieses Token nicht oder es ist nicht freigegeben. | | 429 | rate_limited, daily_limit | Zu viele Anfragen oder Tagesgrenze der API-Einsendungen erreicht. | | 502 | form_processing_failed | Die Rechnung konnte nicht erstellt oder versandt werden; nichts wurde zugestellt. | ## Fragen und Antworten ### Welches ZUGFeRD-Profil erzeugt die API? Das Profil EN 16931 (in ZUGFeRD 1 COMFORT genannt): Cross-Industry-Invoice-XML, eingebettet in ein PDF/A-3, identisch mit Factur-X. Das XML wird nach den KoSIT-Regeln geschrieben, die auch die XRechnung verwendet. ### Wie erstelle ich eine XRechnung? Senden Sie die Leitweg-ID der Behörde als invoice.buyerReference und füllen Sie E-Mail-Adressen und Kontaktdaten von Verkäufer und Käufer aus. Die API erstellt dann eine Rechnung nach EN 16931, die den XRechnung-Regeln entspricht, eingebettet im PDF. ### Kann ich die Summen aus meiner Buchhaltung übergeben? Ja. Werte in totals (lineTotal, taxTotal, grandTotal) und items[].lineTotal haben Vorrang vor der Berechnung. ### Wird die Rechnung automatisch per E-Mail versandt? Ja, wie beim Rechnungs-Webformular: an den Geschäftsinhaber des Formulars und an die E-Mail-Adressen in den Daten. Mit "action": "preview" erhalten Sie das PDF ohne Versand. ### Kann eine Rechnung mehrere Steuersätze haben? Über diesen Endpunkt nicht: Ein Satz gilt für die ganze Rechnung. Senden Sie je Satz eine Rechnung oder nutzen Sie für komplexe Rechnungen das ZUGFeRD Pro SDK. ## Ihre erste E-Rechnung erstellen Fordern Sie Testzugangsdaten an und testen Sie die E-Rechnungs-API auf unserem Online-Server. --- # Webhooks: Webhooks: jede Einsendung direkt in Ihr System. URL: https://www.form-provider.com/de/webhooks.html Ein Webhook schickt jede neue Einsendung eines Formulars an eine Adresse Ihrer Wahl, wenige Sekunden nachdem jemand auf Absenden geklickt hat: CRM, Ticketsystem, ERP, ein Low-Code-Ablauf oder Ihr eigener Dienst. Die Nachricht ist JSON, enthält alle Werte und auf Wunsch das versiegelte PDF und ist signiert, damit Ihr System prüfen kann, dass sie von Ihrem Formularserver stammt. Die Signatur folgt der offenen Spezifikation Standard Webhooks, daher können fertige Bibliotheken in vielen Sprachen sie prüfen. Nicht zustellbare Nachrichten werden 21 Stunden lang wiederholt. ## Kurz gesagt - Ereignis: submission.created für jede echte Einsendung, als JSON, auf Wunsch mit dem versiegelten PDF. - Signatur: Standard Webhooks, HMAC-SHA256 über ID, Zeitstempel und Body (Header webhook-id, webhook-timestamp, webhook-signature). - Zustellung: 7 Versuche über etwa 21 Stunden, nur HTTPS, private Netze abgelehnt, am Ende eine Fehler-E-Mail. ## Inhalt 1. So funktioniert es 2. Einen Webhook einrichten 3. Die Nachricht 4. Die Signatur prüfen 5. Zustellung und Wiederholungen 6. Webhooks verwalten 7. Sicherheit und Datenschutz 8. Fragen und Antworten ## So funktioniert es - Adresse eintragen: über die REST-API für ein Formular (Rolle admin). Die Antwort enthält ein Signaturgeheimnis, das mit whsec_ beginnt; es wird nur einmal angezeigt. - Jemand sendet das Formular ab: im Browser, aus dem PDF oder über die API. Der Server erstellt wie gewohnt das versiegelte PDF und stellt je Webhook eine Nachricht in die Warteschlange. Die Person wartet nicht auf Ihr System. - Ihr Endpunkt erhält einen POST mit den Werten als JSON und drei Headern: webhook-id, webhook-timestamp und webhook-signature. - Signatur prüfen mit dem Geheimnis, dann innerhalb von 15 Sekunden mit einem beliebigen 2xx-Status antworten. Längere Arbeit erst nach der Antwort erledigen. Webhooks ergänzen die E-Mails des Formulars: Der Business Owner erhält PDF und XML weiterhin per E-Mail, außer das Formular ist ohne E-Mail eingerichtet. ## Einen Webhook einrichten Sie brauchen ein Access Token eines Benutzers mit der Rolle admin in der Gruppe des Formulars (siehe Bearer-Token erhalten). Die Adresse muss mit https:// beginnen und aus dem Internet erreichbar sein; Adressen in privaten Netzen werden abgelehnt, außer der Administrator erlaubt sie. curl -X POST https://forms.example.com/api/v1/forms/contact/webhooks \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"url": "https://crm.example.com/hooks/eforms", "description": "CRM import", "includePdf": true, "failureEmails": ["it@example.com"]}' HTTP/1.1 201 Created { "id": "wh_3f2a9c1d0b7e4a6c5d8e", "formId": "contact", "url": "https://crm.example.com/hooks/eforms", "events": ["submission.created"], "active": true, "includePdf": true, "failureEmails": ["it@example.com"], "secret": "whsec_MfKQ9r8GKYqrTwjUPD8ILPZIo2LaLaSw", … } # send a test message and see what the receiver answered curl -X POST -H "Authorization: Bearer $TOKEN" \ https://forms.example.com/api/v1/forms/contact/webhooks/wh_3f2a9c1d0b7e4a6c5d8e/test { "delivered": true, "httpStatus": 200, "durationMs": 184 } - includePdf hängt jeder Nachricht das eingesandte PDF als Base64 an (bis 10 MB). Ohne die Option enthält die Nachricht nur die Werte. - failureEmails (bis zu fünf Adressen) werden benachrichtigt, wenn eine Nachricht nach allen Versuchen nicht zugestellt werden konnte. - Bewahren Sie das Geheimnis im Geheimnisspeicher Ihres Systems auf. Verloren? POST …/webhooks/{id}/rotate-secret erzeugt ein neues; das alte gilt sofort nicht mehr. ## Die Nachricht Jede Nachricht ist ein JSON-Objekt mit type, timestamp und data. Das Ereignis submission.created enthält die Formular-ID, die Einsendungs-ID (dieselbe, die die API bei API-Einsendungen zurückgibt), die Einsendungsreferenz, die Zeit und die Werte nach Feldname. Steuerfelder des Webformulars (Bot-Prüfung, Passwörter des verschlüsselten Archivs) sind nie enthalten. POST /hooks/eforms HTTP/1.1 Host: crm.example.com Content-Type: application/json User-Agent: CodeB-eForms-Server-Webhooks/1.0 webhook-id: msg_2b8f0c6e9a1d4f7b3c5e8a90 webhook-timestamp: 1791802200 webhook-signature: v1,K5oZfzN95Z9UVu1EsfQmfVNQhnkZ2pj9o9NDN/H/pI4= { "type": "submission.created", "timestamp": "2026-10-12T09:30:00Z", "data": { "formId": "contact", "submissionId": "5d0c2f4e8b1a4c7e9f3b2a1d6e5c4b3a", "reference": "contact/118/26", "submittedAt": "2026-10-12T09:30:00Z", "values": { "FirstName": "Erika", "Surname": "Muster", "Email": "erika@example.com" }, "pdf": { "fileName": "contact.pdf", "contentType": "application/pdf", "size": 48211, "data": "JVBERi0xLjcK…" } } } Die Testnachricht hat den Typ webhook.test. Die OpenAPI-Beschreibung führt beide Ereignisse unter webhooks mit ihrem JSON Schema, sodass Codegeneratoren die Empfangstypen erzeugen können. ## Die Signatur prüfen Die Signatur ist v1, gefolgt vom Base64-kodierten HMAC-SHA256 über webhook-id + "." + webhook-timestamp + "." + Body. Der Schlüssel ist der Base64-dekodierte Teil des Geheimnisses nach whsec_. Verwenden Sie den unveränderten Body, bevor Sie JSON auswerten, und vergleichen Sie in konstanter Zeit. Lehnen Sie Nachrichten ab, die älter als fünf Minuten sind, und merken Sie sich die webhook-id verarbeiteter Nachrichten, um Wiederholungen zu ignorieren. ### Node.js const crypto = require("node:crypto"); // rawBody: the request body exactly as received (string), before any JSON parsing function verifyWebhook(secret, headers, rawBody) { const id = headers["webhook-id"], ts = headers["webhook-timestamp"]; if (!id || !ts || Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false; const key = Buffer.from(secret.replace(/^whsec_/, ""), "base64"); const expected = crypto.createHmac("sha256", key).update(`${id}.${ts}.${rawBody}`).digest("base64"); return (headers["webhook-signature"] || "").split(" ").some(part => { const [version, sig] = part.split(","); return version === "v1" && sig && sig.length === expected.length && crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected)); }); } ### Python import base64, hashlib, hmac, time def verify_webhook(secret: str, headers: dict, raw_body: bytes) -> bool: msg_id, ts = headers.get("webhook-id", ""), headers.get("webhook-timestamp", "0") if not msg_id or abs(time.time() - int(ts)) > 300: return False key = base64.b64decode(secret.removeprefix("whsec_")) mac = hmac.new(key, f"{msg_id}.{ts}.".encode() + raw_body, hashlib.sha256).digest() expected = base64.b64encode(mac).decode() return any(hmac.compare_digest(part[3:], expected) for part in headers.get("webhook-signature", "").split() if part.startswith("v1,")) # or with the reference library: pip install standardwebhooks # from standardwebhooks import Webhook; Webhook(secret).verify(raw_body, headers) ### C# (.NET) using System.Security.Cryptography; using System.Text; static bool VerifyWebhook(string secret, string id, string ts, string signatures, string rawBody) { if (Math.Abs(DateTimeOffset.UtcNow.ToUnixTimeSeconds() - long.Parse(ts)) > 300) return false; var key = Convert.FromBase64String(secret.StartsWith("whsec_") ? secret.Substring(6) : secret); using var hmac = new HMACSHA256(key); var expected = Convert.ToBase64String(hmac.ComputeHash(Encoding.UTF8.GetBytes($"{id}.{ts}.{rawBody}"))); foreach (var part in signatures.Split(' ')) { var p = part.Split(',', 2); if (p.Length == 2 && p[0] == "v1" && CryptographicOperations.FixedTimeEquals(Encoding.ASCII.GetBytes(p[1]), Encoding.ASCII.GetBytes(expected))) return true; } return false; } ### PHP function verify_webhook(string $secret, string $id, string $ts, string $signatures, string $rawBody): bool { if (abs(time() - (int)$ts) > 300) return false; $key = base64_decode(preg_replace('/^whsec_/', '', $secret)); $expected = base64_encode(hash_hmac('sha256', "$id.$ts.$rawBody", $key, true)); foreach (explode(' ', $signatures) as $part) { [$version, $sig] = array_pad(explode(',', $part, 2), 2, ''); if ($version === 'v1' && hash_equals($expected, $sig)) return true; } return false; } // $rawBody = file_get_contents('php://input'); ## Zustellung und Wiederholungen Eine Nachricht gilt als zugestellt, wenn Ihr Endpunkt innerhalb von 15 Sekunden mit einem 2xx-Status antwortet. Sonst wird sie mit derselben webhook-id erneut gesendet: | Versuch | Wann | Hinweis | |---|---|---| | 1 | Sofort, wenige Sekunden nach der Einsendung | Weiterleitungen werden nicht befolgt. | | 2 | 1 Minute später | | | 3 | 5 Minuten später | | | 4 | 30 Minuten später | | | 5 | 2 Stunden später | | | 6 | 6 Stunden später | | | 7 | 12 Stunden später | Etwa 21 Stunden nach der Einsendung. Danach geht die Fehler-E-Mail hinaus und die Nachricht bleibt 7 Tage für den Administrator gespeichert. | | – | Antwort 410 Gone | Keine weiteren Versuche für diese Nachricht. | ## Webhooks verwalten Alle Pfade relativ zu /api/v1, Rolle admin erforderlich. PATCH und DELETE funktionieren auch als POST mit dem Header X-HTTP-Method-Override. | Methode | Pfad | Was er tut | |---|---|---| | GET | /forms/{formId}/webhooks | Die Webhooks eines Formulars mit dem Ergebnis der letzten Zustellung. | | POST | /forms/{formId}/webhooks | Webhook anlegen; die Antwort enthält das Geheimnis. | | GET | /forms/{formId}/webhooks/{webhookId} | Ein Webhook. | | PATCH | /forms/{formId}/webhooks/{webhookId} | Adresse, Beschreibung, includePdf, failureEmails ändern oder mit "active": false abschalten (wartende Nachrichten entfallen). | | DELETE | /forms/{formId}/webhooks/{webhookId} | Löschen; wartende Nachrichten entfallen. | | POST | /forms/{formId}/webhooks/{webhookId}/test | webhook.test jetzt senden und die Antwort zeigen. | | POST | /forms/{formId}/webhooks/{webhookId}/rotate-secret | Neues Geheimnis. | | GET | /usage | Wartende Nachrichten und fehlgeschlagene der letzten 7 Tage (Administratoren). | ## Sicherheit und Datenschutz - Nur HTTPS mit Zertifikatsprüfung. Adressen, die auf den Formularserver selbst oder in private Netze zeigen (10.x, 192.168.x, 172.16–31.x, Link-local, Unique Local IPv6), werden abgelehnt, auch wenn ein Hostname später seine Adresse wechselt. Ein Administrator kann interne Empfänger erlauben (Einstellung Webhooks → Allow addresses in private networks). - Nur Administratoren der Gruppe eines Formulars können Webhooks anlegen, denn ein Webhook erhält jeden Wert jeder Einsendung. - Geheimnisse werden mit dem Windows-Datenschutz des Servers (DPAPI) verschlüsselt gespeichert. Nach einem Umzug auf einen anderen Rechner erneuern Sie sie. - Daten auf dem Server: Eine Nachricht bleibt nur bis zur Zustellung auf dem Server. Nachrichten, deren Versuche alle scheitern, werden nach 7 Tagen gelöscht (einstellbar). Darüber hinaus speichert der Server standardmäßig keine Kopie der Einsendungen. - Jede Nachricht ist eine gewöhnliche HTTPS-Anfrage Ihres Formularservers; Ihre Firewall kann dessen Adresse freigeben. Bei einem gehosteten Server nennen wir Ihnen die Adresse. ## Fragen und Antworten ### Was ist ein Formular-Webhook? Eine HTTPS-Anfrage, die der Formularserver bei jeder Einsendung an Ihr System schickt. Sie enthält die eingesandten Werte als JSON (und auf Wunsch das PDF), sodass Ihr CRM, ERP oder Ablauf die Daten erhält, ohne dass jemand sie aus einer E-Mail abtippt. ### Woran erkenne ich, dass ein Webhook wirklich von meinem Formularserver kommt? Jede Nachricht ist mit HMAC-SHA256 und einem Geheimnis signiert, das nur Sie und der Formularserver kennen, nach der Spezifikation Standard Webhooks. Prüfen Sie den Header webhook-signature wie auf dieser Seite gezeigt oder mit einer Standard-Webhooks-Bibliothek und lehnen Sie Nachrichten ab, die älter als fünf Minuten sind. ### Was passiert, wenn mein System nicht erreichbar ist? Die Nachricht wird nach 1 Minute, 5 Minuten, 30 Minuten, 2, 6 und 12 Stunden mit derselben webhook-id wiederholt. Scheitern alle sieben Versuche, werden die Fehler-E-Mail-Adressen des Webhooks benachrichtigt, und die Nachricht bleibt 7 Tage gespeichert. ### Kann ich auch das PDF erhalten? Ja. Mit "includePdf": true enthält jede Nachricht das eingesandte, versiegelte PDF als Base64, bis 10 MB. ### Lösen Einsendungen über die API Webhooks aus? Ja. Jede echte Einsendung tut das: aus dem Browser, aus dem PDF im Adobe Reader und über die API. Ein PDF mit /fill ausfüllen oder Speichern im Browser löst keinen aus. ### Funktionieren Webhooks mit Zapier, Make oder Power Automate? Ja. Tragen Sie die Catch-Hook- oder HTTP-Trigger-URL des Ablaufs als Webhook-Adresse ein. Kann das Werkzeug keine Signaturen prüfen, nutzen Sie zumindest eine lange, geheime URL und prüfen Sie den webhook-timestamp. ### Wie viele Webhooks kann ein Formular haben? Standardmäßig bis zu 10; der Administrator kann die Grenze ändern. ## Formulare anbinden Fordern Sie Testzugangsdaten an und binden Sie ein Formular unseres Online-Servers an Ihr eigenes System an. --- # Beispiele: Ausprobieren, bevor Sie entscheiden. URL: https://www.form-provider.com/de/samples.html Diese Beispielformulare laufen auf diesem Server. Öffnen Sie sie im gewünschten Format, füllen Sie sie aus und reichen Sie sie ein: Sie erhalten das Ergebnis als versiegeltes PDF. ## Kurz gesagt - Kein Konto nötig: die Beispielformulare laufen auf diesem Server; ausfüllen und absenden. - Formate: jedes Beispiel öffnet als responsives HTML, statisches HTML oder ausfüllbares PDF. - Ergebnis: Sie erhalten die Einsendung als versiegeltes PDF per E-Mail; das ZUGFeRD-Beispiel liefert eine E-Rechnung. ## Beispielformulare - **My Health: Zugriff für Ärzte**: Einwilligung mit zwei handschriftlichen Unterschriften, Patient und Arzt, per Touchscreen oder Maus (englisch). https://www.form-provider.com/pdfforms.aspx?fid=myhealth (add &pdf=1, &static=1 or &web=1) - **Mieterklärung**: Zwei Seiten. Der Mietvertrag muss vor dem Einreichen angehängt werden; Bilder werden zu PDF-Seiten, andere Dateien gezippt (englisch). https://www.form-provider.com/pdfforms.aspx?fid=rentaldeclaration (add &pdf=1, &static=1 or &web=1) - **Besichtigungsbestätigung**: Makler und Kunde bestätigen eine Besichtigung und unterschreiben beide am Bildschirm (englisch). https://www.form-provider.com/pdfforms.aspx?fid=propertyvisit (add &pdf=1, &static=1 or &web=1) - **Meldeschein für Hotels**: Digitaler Meldeschein für Beherbergungsstätten nach §§ 29, 30 BMG, mit handschriftlicher Unterschrift am Bildschirm oder Tablet an der Rezeption. https://www.form-provider.com/pdfforms.aspx?fid=meldeschein (add &pdf=1, &static=1 or &web=1) - **ZUGFeRD-Testrechnung**: Rechnung ausfüllen und eine ZUGFeRD- / XRechnung-E-Rechnung erhalten: PDF/A-3 mit eingebettetem XML nach EN 16931. Nur Testdaten. https://www.form-provider.com/pdfforms.aspx?fid=zugferd (add &pdf=1, &static=1 or &web=1) ## Was ist ZUGFeRD? ZUGFeRD ist der deutsch-französische Standard für elektronische Rechnungen, identisch mit Factur-X in Frankreich. Eine ZUGFeRD-Rechnung ist ein PDF/A-3, das Menschen wie jedes PDF lesen, mit den Rechnungsdaten als eingebettetem XML nach der europäischen Norm EN 16931, sodass die Buchhaltungssoftware sie ohne Abtippen verbuchen kann. Für Rechnungen an deutsche Behörden ist das Profil XRechnung vorgeschrieben. In Deutschland müssen Unternehmen seit dem 1. Januar 2025 E-Rechnungen empfangen können; die Pflicht zum Ausstellen folgt in Stufen bis 2028. Mit der ZUGFeRD-Testrechnung oben sehen Sie es in der Praxis: Jede Einreichung wird zu einer gültigen E-Rechnung. Unternehmen ohne eigene Rechnungssoftware können ihre Rechnungsvorlage auf dem eForms Server gestalten und so konforme Rechnungen versenden. Mehr zur E-Rechnung und unsere Werkzeuge zum Erstellen, Auslesen und Umwandeln von ZUGFeRD- und XRechnung-Rechnungen, auch als Webservice, finden Sie auf www.zugferdpro.com. ## Weitere Beispielformulare - **Kontaktanfrage**: Kurzes Kontaktformular mit Einwilligung (englisch). https://www.form-provider.com/pdfforms.aspx?fid=contactrequest (add &pdf=1, &static=1 or &web=1) - **Veranstaltungsanmeldung**: Anmeldung mit Ticketwahl, Workshops und Essenswünschen (englisch). https://www.form-provider.com/pdfforms.aspx?fid=eventregistration (add &pdf=1, &static=1 or &web=1) - **Personalbogen für neue Mitarbeiter**: Persönliche Daten und Bankverbindung für das Onboarding (englisch). https://www.form-provider.com/pdfforms.aspx?fid=employeeonboarding (add &pdf=1, &static=1 or &web=1) - **Spesenabrechnung**: Reise- und Spesenabrechnung mit Summen (englisch). https://www.form-provider.com/pdfforms.aspx?fid=expenseclaim (add &pdf=1, &static=1 or &web=1) ## Häufige Fragen ### Gibt es einen digitalen Meldeschein für Hotels? Ja. Das Beispiel „Meldeschein für Hotels“ zeigt den Meldeschein für Beherbergungsstätten nach §§ 29 und 30 Bundesmeldegesetz (BMG). Gäste füllen ihn am Tablet an der Rezeption oder auf dem eigenen Smartphone aus und unterschreiben handschriftlich am Bildschirm; das Hotel erhält ein versiegeltes PDF und die Daten als XML. Seit dem 1. Januar 2025 ist der Meldeschein nur noch für ausländische Gäste vorgeschrieben. ### Kann ich die Beispielformulare ohne Konto testen? Ja. Die Beispielformulare sind öffentlich: öffnen, mit Testdaten ausfüllen und absenden. Um eigene Formulare zu gestalten, fragen Sie bei info@aloaha.com nach einer kostenlosen Online-Präsentation oder einer 30-Tage-Testversion. ### Was passiert mit den Daten, die ich in ein Beispielformular eingebe? Sie werden zu einem versiegelten PDF und an die angegebene E-Mail-Adresse sowie an den Formularverantwortlichen geschickt. Der Server behält keine Kopie. Bitte verwenden Sie nur Testdaten. ### Welche Beispielformulare gibt es? Einen Meldeschein für Hotels, eine Einwilligung mit zwei Unterschriften, eine Mieterklärung mit Anhang, eine Besichtigungsbestätigung, eine ZUGFeRD-Rechnung sowie Kontakt-, Veranstaltungs-, Personal- und Spesenformulare. Jedes öffnet als responsives HTML, statisches HTML oder ausfüllbares PDF. --- # Online testen: Den Formularserver testen, online, mit Ihren eigenen Formularen. URL: https://www.form-provider.com/de/aloaha-demo-form-server.html Jeder kann den CodeB eForms Server auf unserem Online-Server ausprobieren. Schreiben Sie uns, und wir senden Ihnen Testzugangsdaten: Sie gestalten eigene Formulare im Browser, veröffentlichen sie und füllen sie aus, am Desktop und auf dem Smartphone. Kostenlos und unverbindlich. Bitte nur Testdaten verwenden. ## Kurz gesagt - Wer: jeder, der den CodeB eForms Server prüfen möchte, kann per E-Mail Testzugangsdaten anfordern. - Was: eigene Formulare gestalten, als PDF und HTML veröffentlichen, unterschreiben, E-Rechnungen erstellen und die REST-API aufrufen. - Daten: bitte nur Testdaten verwenden; Einsendungen gehen per E-Mail und bleiben nicht auf dem Server. ## So erhalten Sie Ihren Testzugang 1. Schreiben Sie an info@aloaha.com mit dem Betreff „Testzugang“ und sagen Sie uns kurz, was Sie ausprobieren möchten. 2. Wir richten ein Testkonto für Sie ein und senden Ihnen die Adresse des Servers und Ihre Zugangsdaten. 3. Melden Sie sich an, öffnen Sie die Formularbibliothek und legen Sie Ihr erstes Formular an, oder beginnen Sie mit einem Beispiel. 4. Geben Sie das Formular frei und füllen Sie es aus: Sie erhalten das versiegelte PDF per E-Mail. ## Was Sie ausprobieren können - **Formular-Editor**: Gestalten Sie ein Formular im WYSIWYG-Editor, am Desktop, auf dem Tablet oder Smartphone. - **PDF und HTML**: Dasselbe Formular als ausfüllbares PDF, responsives HTML und statisches HTML. - **Signaturen**: Handschriftliche Unterschrift am Bildschirm, versiegelte PDFs, Zeitstempel. - **E-Rechnungen**: Aus einem Rechnungsformular werden ZUGFeRD- / XRechnung-E-Rechnungen. - **Anmeldung und EUDI-Wallet**: Formulare mit Anmeldepflicht, vorbefüllt mit geprüften Daten. - **REST-API**: Formulare und Felder auflisten, Daten absenden und E-Rechnungen aus Ihrer Software erstellen. ## Gut zu wissen - Der Testserver dient zum Ausprobieren. Bitte nur Testdaten verwenden, keine echten personenbezogenen Daten. - Eingesandte Formulare gehen per E-Mail an die Adressen, die Sie eingeben; der Server speichert keine Kopie. - Sie möchten es erst sehen? Gern zeigen wir Ihnen den Formularserver in einer kostenlosen Online-Präsentation. - Im eigenen Betrieb läuft der Formularserver auf Windows Server und IIS in Ihrem Rechenzentrum oder gehostet bei Aloaha. ## Fragen und Antworten ### Wer erhält Testzugangsdaten? Jeder: Unternehmen, Behörden, Entwickler und Partner. Schreiben Sie an info@aloaha.com und sagen Sie uns kurz, was Sie testen möchten. ### Was kostet der Test? Nichts. Der Testzugang ist kostenlos und unverbindlich. ### Kann ich auch die REST-API testen? Ja. Sagen Sie uns, dass Sie die API testen möchten: Sie erhalten ein Anmeldekonto, dessen Token die API annimmt, und können Formulare auflisten, Daten absenden und E-Rechnungen erstellen. ### Kann ich die Beispielformulare ohne Zugangsdaten ausprobieren? Ja. Die Beispielformulare sind öffentlich; Zugangsdaten brauchen Sie nur, um eigene Formulare zu gestalten. ### Wie schnell erhalte ich Testzugangsdaten? Wir beantworten Anfragen per E-Mail; schreiben Sie an info@aloaha.com mit Ihrem Namen und Ihrer Organisation. ## Testzugang anfordern Eine E-Mail genügt. --- # Rechtliches: Impressum URL: https://www.form-provider.com/de/imprint.html Rechtliche Angaben für diese Website und das Produkt CodeB eForms Server. Anbieter ist die Aloaha Limited, eine in Malta registrierte Gesellschaft. Dieselbe Rechtsperson betreibt auch www.aloaha.com, www.zugferdpro.com und www.codeb.io. ## Anbieter Aloaha Limited „Helgoland“ 45, Triq Gio Felice Inglott Pembroke PBK1131 Malta ## Unternehmensangaben | Angabe | Wert | |---|---| | Rechtsform | Private Limited Company (Limited) | | Sitz | Pembroke, Malta | | Rechtsraum | Republik Malta, EU-Mitgliedstaat | | USt-ID | MT14814406 | ## Kontakt E-Mail: info@aloaha.com Telefon: +49 541 3859 4554 und +49 151 5761 0183 Erreichbarkeit: Montag bis Freitag zu den üblichen Geschäftszeiten (MEZ), auf Deutsch und Englisch Internet: www.aloaha.com Jede E-Mail an info@aloaha.com wird von einem Mitarbeiter aus Technik oder Vertrieb gelesen und beantwortet. ## Verantwortlich für den Inhalt Büro der Geschäftsführung, Aloaha Limited, postalisch über die oben angegebene Anschrift, per E-Mail über info@aloaha.com. ## Verbraucherstreitbeilegung Die Aloaha Limited ist nicht verpflichtet und nicht bereit, an einem Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen. ## Marken „Aloaha“, „CodeB“, „CodeB Identity Solutions“ und das CodeB-Logo sind Marken der Aloaha Limited. Marken Dritter, unter anderem Adobe, Acrobat, ZUGFeRD, Factur-X, Microsoft, Windows, Azure und .NET, sind Eigentum der jeweiligen Inhaber und werden nur zu beschreibenden Zwecken genannt. ## Haftung für Inhalte Die Inhalte dieser Website wurden mit größter Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte übernimmt die Aloaha Limited jedoch keine Gewähr. Als Diensteanbieter sind wir für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. ## Haftung für Links Externe Links führen zu Websites Dritter, auf deren Inhalte wir keinen Einfluss haben; für diese Inhalte ist stets der jeweilige Anbieter verantwortlich. Zum Zeitpunkt der Verlinkung waren keine Rechtsverstöße erkennbar. Werden uns Rechtsverletzungen bekannt, entfernen wir die betreffenden Links umgehend. ## Urheberrecht Die Inhalte und Werke auf dieser Website unterliegen dem Urheberrecht. Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechts bedürfen der vorherigen Zustimmung der Aloaha Limited. --- # Rechtliches: Datenschutzerklärung URL: https://www.form-provider.com/de/privacy.html Diese Seite erklärt, was mit Ihren Daten geschieht, wenn Sie diese Informationsseiten besuchen und wenn Sie mit dem eForms Server Formulare ausfüllen oder gestalten. ## Verantwortlicher Aloaha Limited, „Helgoland“ 45, Triq Gio Felice Inglott, Pembroke PBK1131, Malta E-Mail: info@aloaha.com, Telefon: +49 541 3859 4554. Weitere Angaben im Impressum. Nutzen Sie ein Formular, das eine andere Organisation auf diesem Server veröffentlicht, ist diese für die Formulardaten verantwortlich; Aloaha verarbeitet sie in deren Auftrag. ## Informationsseiten: was wir nicht tun - Keine Cookies auf den Informationsseiten, weder eigene noch von Dritten. - Keine Analyse- oder Statistikdienste, keine Werbe- oder Tracking-Pixel, kein Fingerprinting. - Keine externen Schriftarten oder CDNs: Schriften, Stile und Bilder liefert dieser Server aus. ## Server-Protokolle Wie jeder Webserver protokolliert dieser Server technische Zugriffsdaten: IP-Adresse, Datum und Uhrzeit, aufgerufene Adresse, Statuscode, übertragene Datenmenge, Referrer und Browserkennung (User-Agent). Diese Daten brauchen wir, um Website und Formulare sicher auszuliefern und Angriffe abzuwehren. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am sicheren Betrieb). Wir werten sie nicht zu Werbe- oder Profilzwecken aus, führen sie nicht mit anderen Daten zusammen und geben sie nicht weiter. ## Nutzung des Formularservers Wenn Sie sich anmelden oder ein Formular ausfüllen, verwendet der Server ein Sitzungs-Cookie und nach der Anmeldung Cookies, die Sie angemeldet halten. Sie sind für diese Funktionen technisch notwendig (Art. 6 Abs. 1 lit. b und f DSGVO) und verfallen mit der Abmeldung oder dem Ende der Sitzung. Gemerkte Eingaben: Damit Sie nicht alles erneut eintippen müssen, speichert Ihr Browser Ihre Eingaben in einem Formular in seinem lokalen Speicher, für jedes Formular getrennt und höchstens 90 Tage. Diese Eingaben bleiben auf Ihrem Gerät und werden nicht an uns übertragen. Passwörter, Unterschriften, Anhänge und Zahlungsdaten werden nie gespeichert. Mit „Löschen“ im Hinweis am Formular oder durch Löschen der Websitedaten im Browser entfernen Sie sie. Bot-Schutz: Gegen automatisierten Spam enthält die Formularseite eine unsichtbare Prüfung. Ihr Browser berechnet im Hintergrund einen kurzen Wert, und der Server prüft ihn zusammen mit der Zeit zwischen Öffnen und Absenden des Formulars. Dafür werden keine personenbezogenen Daten verwendet, kein Cookie gesetzt und kein Drittanbieter eingebunden. Eingereichte Formulare: Ihre Eingaben und Anhänge werden genutzt, um ein versiegeltes PDF und eine XML-Datei zu erzeugen. Diese gehen per E-Mail an Sie (sofern Sie eine E-Mail-Adresse angegeben haben) und an die zuständige Stelle des Formulars. Standardmäßig behält der Server keine Kopie; hat die zuständige Stelle das verschlüsselte Archiv aktiviert, wird ein passwortgeschütztes PDF aufbewahrt, das sich nur mit der Einreichungs-ID öffnen lässt. Anmeldung über einen Identitätsanbieter: Melden Sie sich mit einem Aloaha- oder CodeB-Konto an (www.aloaha.com, phone.codeb.io oder phone.aloaha.com) oder verlangt ein Formular eine Anmeldung, werden Sie zum Anbieter weitergeleitet, und wir erhalten die für die Anmeldung (etwa Name, E-Mail-Adresse und Rolle) und, falls das Formular es nutzt, für die Vorbefüllung nötigen Identitätsdaten. Webhooks: Hat der Inhaber eines Formulars einen Webhook eingerichtet, werden die eingesandten Daten (und, falls gewählt, das PDF) zusätzlich per HTTPS an ein vom Formularinhaber benanntes System übermittelt, etwa sein CRM. Bis zur Zustellung wartet die Nachricht auf dem Server; nicht zustellbare Nachrichten werden spätestens nach 7 Tagen gelöscht. Für das empfangende System ist der Formularinhaber verantwortlich. Vorausgefüllte Links: Haben Sie einen Link erhalten, der ein Formular mit Ihren Daten öffnet, hat der Formularinhaber diese Werte dafür auf dem Server gespeichert. Sie werden gelöscht, wenn der Link abläuft (standardmäßig nach 7 Tagen, spätestens nach 90 Tagen) oder der Inhaber ihn widerruft. ## Kontakt per E-Mail oder Telefon Wenn Sie uns schreiben oder anrufen, verarbeiten wir Ihre Angaben (Name, E-Mail-Adresse, Telefonnummer, Inhalt der Anfrage), um Ihr Anliegen zu bearbeiten. Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO, wenn Ihre Anfrage auf einen Vertrag zielt, sonst Art. 6 Abs. 1 lit. f DSGVO. Wir löschen die Daten, wenn sie nicht mehr benötigt werden, sofern keine gesetzlichen Aufbewahrungsfristen bestehen. ## Ihre Rechte Sie haben das Recht auf Auskunft (Art. 15 DSGVO), Berichtigung (Art. 16), Löschung (Art. 17), Einschränkung der Verarbeitung (Art. 18), Datenübertragbarkeit (Art. 20) und Widerspruch gegen Verarbeitungen auf Grundlage berechtigter Interessen (Art. 21). Eine erteilte Einwilligung können Sie jederzeit mit Wirkung für die Zukunft widerrufen. Eine E-Mail an info@aloaha.com genügt. Sie können sich außerdem bei einer Datenschutz-Aufsichtsbehörde beschweren, etwa bei der für uns zuständigen maltesischen Behörde, dem Information and Data Protection Commissioner (IDPC), oder bei der Behörde Ihres Wohnorts oder Arbeitsplatzes. ## Keine automatisierten Entscheidungen Wir treffen keine automatisierten Entscheidungen und erstellen keine Profile im Sinne von Art. 22 DSGVO. ## Sicherheit Website und Formulare werden ausschließlich verschlüsselt über HTTPS ausgeliefert. Stand: Oktober 2026