Aura Historia Partner Connect

Yes. This plugin is intended for merchants who already use Aura Historia and administer a ListingSource they can authorize during OAuth.

The plugin registers each connection attempt with Aura Historia from your server and keeps a one-time secret on your server. Aura Historia returns your browser with an opaque completion code, and the plugin redeems that code together with the secret, server to server. The access token and ListingSource come only from that response; nothing the browser adds can change them. Each attempt can complete once, within 15 minutes, for the administrator who started it. Starting again replaces an unfinished attempt. A denied, expired or failed attempt leaves an existing connection unchanged; start again from the settings page.

Only product.created , product.updated , and product.deleted . The plugin’s own product.deleted webhook fires when a product is trashed and also when a product is deleted permanently, with or without Trash first. Deleting a single variation does not remove its parent product from Aura Historia. Your own WooCommerce webhooks keep their default behavior.

After configuration, the plugin sends the generated WooCommerce webhook secret, store language and currency, unchanged signed live product webhook payloads, published product listing data during backfill, and typed shipping rules and item inputs during shipping import. The backfill never sends description/body; live WooCommerce webhook bodies remain untouched. See External services above.

No. The plugin keeps the Aura Historia delivery URL built in and generates the WooCommerce webhook secret automatically.

A background reconciliation repairs it shortly afterwards. Deleting a managed webhook triggers a sync, and so does any difference between its name, topic, status, delivery URL, secret, user or API version and what the plugin applies, including WooCommerce disabling it after repeated failed deliveries. Reactivation resets its failure count. WooCommerce’s own save after each delivery, which only records the failure count, does not trigger a sync. The plugin first stages all managed webhooks paused with the desired signing secret, then applies that secret, supported store currency, and language through the WooCommerce ingestion-configuration PUT. Only after it succeeds does sync activate the webhooks. Only one request synchronizes at a time, so simultaneous requests cannot create duplicate webhooks or activate a different connection, currency or language than the one registered. Reconnecting or changing WooCommerce currency or WordPress site language pauses delivery immediately until the new configuration is registered. Unsupported store currencies or configuration failures leave them paused for retry.

Yes. Once configuration succeeds, the plugin schedules an initial backfill once per canonical lowercase UUIDv7 ls_ ListingSource ID. If setup or queueing fails, it keeps that first run pending for a later healthy request. It submits published products in background batches of up to 100 to the async ProductListings API. A 202 confirms queue admission, not completed creation or immediate search visibility. Retries reuse the same ordered request and idempotency key; a product-ID cursor prevents skips when earlier products are removed. Routine webhook repairs never start a fresh CREATE run. The manual action safely resumes pending work without changing its snapshot/key, leaves already queued work alone, or starts a new full run only when idle, and its confirmation states which one happened. Overlapping background callbacks never submit the same page twice with different keys, and work started before a cancellation or reconnect cannot overwrite the current run. A batch that keeps failing with a timeout, HTTP 408, 429 or 5xx is retried after 1, 2, 4, 8, 16 and 32 minutes and then hourly, and after 10 failed attempts in a row every 6 hours until it is admitted, always with the same request and key.

Storefront and other ordinary requests never contact Aura Historia, so an outage cannot slow them down. Webhook configuration is confirmed by a background Action Scheduler job, queued once per attempt. Timeouts, HTTP 408, 429 and 5xx responses are retried after 1, 2, 4, 8, 16 and 32 minutes and then hourly; after 10 failed attempts in a row, about four hours, the plugin keeps trying every 6 hours. Other errors, such as a revoked token, are shown as needing attention and are also retried every 6 hours. Retries never stop on their own, so delivery resumes without any action once Aura Historia is reachable again. Delivery stays paused until the configuration is confirmed. Sync webhooks now , reconnecting, changing the store currency or site language, reactivating or updating the plugin try again at once.

Plugin-owned webhooks are paused on deactivation so WooCommerce stops sending deliveries. Queued webhook reconciliation and backfill work is stopped. Reactivation reconciles the webhooks again, while a stopped backfill keeps its pending batch for the manual resume action. Shipping jobs are fenced/canceled, and the plugin attempts protected retirement of its shared shipping profile and clearing of its source default. This is not source authorization revocation. Unconfirmed cleanup is visible after reactivation; review retained assertions in Aura Historia. Existing assertions have no automatic expiry.

Ordered zones including fallback zone 0, country restrictions, reviewed state codes, exact postcodes and reviewed German postcode forms, core constant/quantity flat rates, bounded per-class quantity charges, conditional free shipping and conservative local pickup. Shared base/class surcharges, per-order class maxima, coupon/tax/cart context, unreviewed geography, third-party methods and other expressions remain uncertain or externally calculated. Nothing runs checkout or evaluates arbitrary expressions. Zones without locations retain their position and cover the permitted shipping countries. Class charges are ignored when no shipping classes exist, matching WooCommerce. The complete support matrix is in the repository README.

Import shipping resumes immutable pending work and retries missing catalog listings without recreating products. Each background action makes at most one write; automatic retries and retained deferred work are bounded. Progress, manual protection and capability limits appear on the settings page. Shipping policy is shared in profiles, while item inputs remain separate. Incomplete reads preserve previous assertions; only confirmed local removals or complete scoped replacement remove owned assertions. Manual edits remain protected. A restored product cancels unsent removals and refreshes its selection and inputs. When Trash has already withdrawn a product’s Aura Historia listing, Aura refuses to clear its shipping. The plugin does not report that removal as done and does not retry it periodically. It continues with other products, never restores the listing, and counts these products on the settings page. Restoring the product publishes its current shipping again.

Local hooks observe zone/location/order changes (including fallback zone 0), method addition/deletion/enablement and instance settings, shipping classes, core settings/units/currency, product inputs and variation inheritance. Save requests only mark durable identities. Background workers reread current facts and reuse the initial/manual publisher. Missed changes converge through six-hour reconciliation with bounded product traversal and pages of 20 previously published identities. Unsupported plugin behavior remains conservative; failed or incomplete reads never establish removal. No shipping refresh recreates catalog products.

WooCommerce Action Scheduler and a working WordPress cron or server runner are required. Low-traffic sites or DISABLE_WP_CRON installations need a server cron trigger or an Action Scheduler CLI runner, for example wp action-scheduler run --group=aura-historia-shipping . No browser session is required. The settings page shows oldest pending/failed work, deferred components, protected edits and last confirmed API write. Search indexing completes separately. Automatic attempts stop after five failures; up to 100 deferred components are retained before stopping at a checkpoint. Repeated refreshes reuse the entry of a component that is already deferred, such as an unsupported product type, and send no new request for a component until its retained request is resolved. Periodic/manual refreshes resume retained work.

Shipping assertions remain valid until updated, withdrawn or their source loses authority, without expiry or keepalive, including after 30 days. Reconnect/reactivation requires a fresh local acquisition; old jobs cannot relabel/replay their captures into a new connection. Valid Aura token rotation preserves immutable retries and uses the current token at execution. Deactivation/reconnect/uninstall attempt existing protected cleanup where possible and record whether it committed. Cleanup preserves manual terms and does not revoke authorization. Uninstall removes local shipping jobs/state and records a bounded diagnostic if remote cleanup was not confirmed. Lost credentials or unreachable Aura can leave assertions eligible until explicitly changed in Aura.