Skip to content
Space Invoices Documentation

WooCommerce Invoicing

Use the native connector to turn WooCommerce orders into documents. For a custom order-to-invoice integration, see E-Commerce.

Connect Your Store

You need an entity admin in Space Invoices and permission to approve the connection in a WooCommerce store that supports REST API v3 and wc-auth.

  1. Select the issuing entity, open Integrations, and choose WooCommerce.
  2. Choose Add store and enter the full HTTPS store URL, including any WordPress subdirectory.
  3. Continue to WooCommerce and approve the requested read_write access.
  4. Return to Space Invoices and confirm the store is connected. Open the store’s settings to review document automation and email delivery.

New connections enable automatic order processing and invoice email. Review those settings before sending new orders through the connector. Connecting does not import historical orders.

Space Invoices stores the issued consumer credentials encrypted and manages active order.created and order.updated webhooks automatically.

Order Processing Rules

Orders are normalized through the same invoicing pipeline as Shopify. A WooCommerce order is paid only when date_paid exists, complete when its status is completed, and terminally cancelled when it is cancelled or moved to trash. Pending online payments are stored but do not create, email, or fiscalize a document; automation resumes once WooCommerce supplies payment confirmation. Cash-on-delivery and bank-transfer orders retain their configured pre-payment document flow. A pending payment that is cancelled never issues a document. A fully refunded order uses the standard invoice-void flow, including fiscalization behavior. Partial refunds update order state but do not automatically void an invoice or create a credit note.

Tax percentages are read from tax_lines[].rate_percent; referenced rates are fetched only when the payload omits the percentage. Compound taxes, unresolved rates, malformed totals, and reconciliation failures leave the order visible with a processing blocker and cannot create a document until corrected and replayed. Plugin-specific VAT numbers, tax clauses, and “sold on behalf of” metadata are not supported in the initial connector release.

Recovering failed order processing

An accepted connector webhook confirms that Space Invoices ingested the order; automatic document work may still be running in the background. If that work fails, the failure is reported to operational monitoring.

Initial processing, estimate conversion, and invoice reissue failures retain the order error and return an error to the API caller. After correcting the underlying problem, retry a failed order with POST /orders/{id}/process or the Reprocess action, including when it already has a linked document. Reissue failures can also be retried with POST /orders/{id}/reissue. Saved documents and payments are reused; a reissue reuses its saved credit note. The order links to a document as soon as it is saved, even if later processing fails.

If the provider changes an order after its document was saved, recovery finishes that document and retains the outstanding change for a subsequent reissue. It does not apply the newer payment or email to an outdated document. Historical partial reissues without a reliable recovery checkpoint require manual reconciliation.

For orders with a linked document created before recovery checkpoints were introduced, payment processing continues without repeating document-creation activity, fiscalization or e-invoice submission. Unknown historical email delivery suppresses an automatic resend but does not block payment recording. An unpaid cash-on-delivery invoice can still send its first email when payment arrives.

Automatic order email failures before dispatch can be retried. If delivery may have been accepted but its result could not be recorded, recovery stops for delivery reconciliation rather than automatically sending another email.

Buyer-facing document language

Order-generated documents resolve their language from provider order or checkout language, then an explicit buyer locale, billing country, shipping country when billing country is absent, and finally the entity locale. WooCommerce language metadata is recognized only from the supported allowlist (wpml_language, _wpml_language, trp_language, weglot_language, and wt_pklist_order_language). Shopify uses customer_locale through the same resolver.

The resolved locale controls PDF labels, filenames, dates, numbers, shareable links, and synthesized shipping or fee names. Provider-supplied product, shipping, and fee names are preserved. The locale freezes after the first invoice or estimate is created, so reissues, conversions, credit notes, and later renders remain consistent. Automated email copy uses a translated entity default when available and otherwise falls back to the entity language without changing the buyer-language PDF.

Historical imports and repair

Connecting or re-enabling a store never imports history automatically. Choose an explicit date range of at most 90 days; the UI defaults to the last seven local calendar days and processes at most four WooCommerce pages before requiring Continue. Eligible imported orders can create and send documents under the integration’s current automation settings. First-seen webhook orders older than the connection are ignored unless they were explicitly introduced by historical sync.

Apollo v1 migrations preserve legacy WooCommerce integration settings, historical order identities, and links to migrated invoices or estimates. Previously disabled stores remain disabled as historical records and do not prompt for reconnection. Because the legacy webhook connector did not retain reusable REST credentials, an active migrated connection remains inactive until an entity admin explicitly reconnects that store and completes WooCommerce authorization. When authorization succeeds, Space Invoices disables the matching legacy connector before activating the new webhooks and performs a bounded overlap sync. If that sync cannot finish immediately, the integration page shows a resumable action until the fixed migration window is complete, so the cutover neither duplicates migrated invoices nor silently loses new orders.

Disabling or deleting a connector first makes it inactive and then removes its remote webhooks. Cleanup failures remain retryable, and re-enabling reconciles webhooks before activation without importing the disabled interval. Revoked WooCommerce credentials require deleting and reconnecting the integration in this release.