Your PDF Was Generated. Was It Actually Delivered?
7 October 2026 · 3 min read
Make Wix document automation recoverable with separate generation and delivery states, safe retries, secure file access and useful status messages.
A user submits a form. The PDF service creates a file. Then the email step fails. Has the automation succeeded?
For the person waiting, the answer is no. For a system that records only “PDF created”, the answer may appear to be yes. Reliable document automation on Wix starts by separating these events and making the unfinished work visible.
Model the stages your team needs to understand
For a typical implementation, we recommend distinct states for submission received, awaiting any required approval, generation in progress, document ready, sending and send failure. The exact names matter less than keeping the events distinguishable.
Email acceptance is another useful milestone, but it does not prove inbox delivery or that someone read the message. If the chosen provider supplies delivery or bounce events, those can update separate fields. Do not display “delivered” based only on a successful request to send.
Give staff a view of records that stopped partway through. A workflow that fails visibly is much easier to support than one that silently loses its last step.
Save the submission before contacting other services
Store a validated submission and its identifier before starting the document request. That provides a durable reference for the rest of the work. Backend code can then coordinate the external service calls supported by the chosen providers.
Wix's Fetch API provides external request capability; it does not itself supply an entire job queue, delivery guarantee or retry policy. Those behaviours need to be designed around the services and triggers in use.
Keep document generation and email sending as separate operations. If the PDF already exists, a failed email should not automatically require regenerating it.
Make retries refer to the same job
A repeated form event, a double-click or a staff retry can accidentally produce several documents and messages. Use a stable job identifier and check the recorded state before taking the next action. This is a recommended application pattern, often called idempotency.
Where a provider supports an idempotency key, use it according to that provider's contract. Where it does not, keep local records of requests and returned file or message IDs. A timeout is ambiguous: the remote service may have completed the work even though your application did not receive the response.
For that reason, retries should be deliberate and bounded. A permanently invalid address or missing template needs correction, not an endless loop.
Choose attachments and download links deliberately
An attachment is convenient but may encounter provider size limits. A download link can simplify large-file delivery, but its access rules need attention. A public media URL is not an authenticated document portal.
For private documents, assess authenticated retrieval or appropriately restricted links supported by your storage choice. Keep sensitive submission details out of routine logs and customer-facing error messages. Record enough operational information to diagnose a failure without copying the document's contents everywhere.
A project example: automated certificate delivery
MIDOC's Wix workflow connected a custom form, PDF generation and email delivery with an attachment. It demonstrates the document-processing journey below. The available project scope does not establish clinical eligibility or practitioner approval logic; any required professional decision remains a distinct prerequisite.
The state model and retry controls in this guide are recommendations for dependable delivery, not claims about every internal control in that project.
Test recovery as well as the happy path
Test an invalid email address, a slow PDF provider, a duplicate event and a failed send after successful generation. Then have a staff member recover each scenario using the tools you provide.
If the only recovery method is “submit the whole form again”, the workflow is not finished. Wix Rocket can help design the status records, retry controls and customer messages around the automation.