Logging

The plugin writes to the WooCommerce logger (wc_get_logger()), so everything lands in WooCommerce → Status → Logs. There is no plugin-specific log screen and no custom retention: WooCommerce’s own file-log rotation applies (logs are kept for the retention period configured under WooCommerce → Status → Logs → Settings, 30 days by default).

Where to read the logs

Open the log screen

Go to WooCommerce → Status → Logs.

Filter by source

Use the source filter dropdown to pick one of the sources below. Each source becomes its own dated log file.

The first source name is misspelled in the code — teamzlab_fedex_shippnig (note shippnig). The typo is load-bearing: it is the literal source string in includes/HTTP/Shipping.php:22, so you must select the misspelled spelling in the dropdown or you will see an empty log.

Active log sources

Five sources are actually written in v1.2.3 (each maps to one wc_get_logger() call site):

Source	Emitting class	Written when	Level	Content
`teamzlab_fedex_shippnig`	`HTTP\Shipping`	Every checkout rate request, per phase (`initial`, `safe_packaging_retry`, `transient_http_retry`)	`info`	See below — verbose only under `WP_DEBUG`
`teamz_shipment_create`	`HTTP\Shipment`	Instant-mode Ship API request and response at checkout	`info`	Full payloads only under `WP_DEBUG`
`teamz_fedex_checkout`	`Frontend\Checkout`	Label purchase failed after the order was created	`error`	`FedEx shipment creation failed after checkout: <message>`; the same text goes to order meta `_fshipping_last_error`
`teamz_fedex_email`	`Email\ShipmentConfirmation`	The scheduled shipment-confirmation email reported a send failure	`warning`	Shipment post id + customer email
`teamz_fedex_webhook`	`Ajax\TrackingWebhookReceiver`	An inbound AIV webhook event was skipped as stale or a duplicate	`info`	Reason line (stale event / duplicate body / duplicate event id)

Detail level: `WP_DEBUG` gate

Both request/response sources are deliberately quiet by default because full FedEx JSON carries customer PII:

teamzlab_fedex_shippnig — with WP_DEBUG on, full request and response JSON per phase (includes the customer destination postcode and cart contents). Without WP_DEBUG, a single non-PII summary line per phase: HTTP status, rate count, requested service, first FedEx error code.
teamz_shipment_create — the full-payload check is defined( 'WP_DEBUG' ) && WP_DEBUG (includes/HTTP/Shipment.php:210 for the request, :239 for the response). Without WP_DEBUG you get Payload: service=<serviceType> packages=<n> and Response: tracking=<number> service=<serviceType> http_status=<code> error_code=<code>.

To capture full wire traffic while reproducing an issue, enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Declared-but-inactive sources

Every HTTP client class declares a $log_source property, but the shared base-client logger is an intentional no-op in this build (includes/Compat/Traits/LogsHttp.php), so no entries are ever written under these sources. They are listed here so you do not go looking for them: fshipping_http (base default), fshipping_address_validation, fshipping_freight_ltl, fshipping_global_trade, fshipping_locations, fshipping_openship, fshipping_pickup, fshipping_postal_code, fshipping_rates, fshipping_return_tag, fshipping_service_availability, fshipping_ship_close, fshipping_ship_retrieve, fshipping_ship_validate, fshipping_tracking, fshipping_aiv, fshipping_trade_docs, fshipping_sandbox_ping.

Open Ship logging surfaces

HTTP\OpenShip has five instrumentation surfaces, all writing to wp-content/debug.log (not the WooCommerce log). In v1.2.3 the three writer methods (debug_log_push_json_blocks(), debug_log_push_message(), emit_openship_log_output() at includes/HTTP/OpenShip.php:2006-2038) are stubbed no-ops, so nothing is emitted today. The surfaces and their gates still matter if you wire the writers or need to know what the filters control:

Surface	Would log	Gate / location
Create wire JSON	Exact JSON bytes sent to `POST /ship/v1/openshipments/create`	`OpenShip.php:433-466`; forced for order-scoped creates via `fshipping_openship_log_create_for_order`, opt-in via `fshipping_openship_log_exact_wire_json_before_create`
Confirm	Request + full response of `POST /ship/v1/openshipments/`	`OpenShip.php:2096-2112`; `fshipping_openship_log_confirm_request_response`, forced when FedEx returns `errors` by `fshipping_openship_force_log_on_fedex_errors`
Delete / bulk audit	Request + response of `PUT /ship/v1/openshipments/delete`	`OpenShip.php:2155-2185`; `fshipping_openship_log_delete_request_response`; bulk Delete permanently passes `force_audit_log = true`
Order-scoped titles	`order_id=<n>` suffix on create/confirm/delete blocks	Title builders in the same methods
Save & push debug	Package add/modify/delete traffic from the order box	`should_log_openship_push_debug()` at `OpenShip.php:2023-2030` — on when `FSHIPPING_OPENSHIP_LOG_PUSH` is truthy, else when `WP_DEBUG && WP_DEBUG_LOG`; filter `fshipping_openship_debug_log_push`

For Open Ship diagnosis today, use order notes and order meta instead — see below.

Staging-mode log

Separate from WooCommerce logging: while the hidden option fshipping_staging_mode is set to yes, Migration\StagingMode::debug_log() appends rate-call events to the option fshipping_staging_log (rolling buffer, last 100 entries). Written by Events\RuntimeIntegrator. No UI reads it in this version — query the option with WP-CLI:

wp option get fshipping_staging_log --format=json

What is never logged

OAuth credentials. The bearer token travels in the Authorization header, and the loggers only serialize request/response bodies, so the token, Client ID, and Client Secret never appear in any log line (includes/HTTP/Shipping.php:365 states this contract in code).
Non-debug lines are PII-free by design — service type, package count, tracking number, HTTP and error codes only.
Under WP_DEBUG, customer PII is logged (name, phone, street address, destination postcode, cart contents). Treat verbose logs as sensitive: do not paste them into public tickets unredacted.

Order notes as the operational log

The most complete per-order history is not a log file at all — it is WooCommerce order notes (all written as admin-only notes, so customers never see them). Events that add a note:

Event	Example note text
Duplicate Ship call blocked	”FedEx shipment already exists for this order; skipped duplicate shipment creation.”
Pre-ship guard skipped the Ship call	”FedEx Ship call skipped by pre-flight guard.”
Address validation fail-open	”FedEx Address Validation did not return a match; shipment allowed by store policy…”
Quota reached at order time	The quota message (label skipped, order kept)
Label purchase failed	”FedEx shipment creation failed after checkout: …”
Open Ship draft created / settings updated / packages pushed / confirmed / session cancelled	”FedEx Open Ship draft created (session …)”, “FedEx Open Ship: shipment confirmed and labels stored.”, …
Instant label canceled	”Shipment canceled”
Return label created	”FedEx return label created — tracking `<number>`.”
Customs events (AIV)	“FedEx customs event `<code>`: …”
Delivery milestones (AIV)	“FedEx confirmed delivery: …”, “FedEx: out for delivery — …”, “FedEx delivery exception: …”
ETD steps	”ETD: commercial invoice uploaded…”, “ETD: all required customs documents uploaded digitally…”
Trade docs uploaded from the admin	”FedEx ETD post-shipment upload succeeded: N document(s) linked to tracking …”

For Open Ship errors that FedEx returned, the raw response is also stored on the order in _fshipping_openship_last_confirm_json and _fshipping_last_error — read those when the debug.log writers are off.

Using logs in support

A reproducible bundle for a “label failed” ticket:

# 1. Note the order id, then read the failure text and FedEx error:
wp post meta get <order_id> _fshipping_last_error
wp post meta get <order_id> _fshipping_openship_last_confirm_json --format=json

# 2. Read today's rate + ship logs (source names are exact, including the typo):
wp post list --post_type=fedex_shipping --field=ID   # did a shipment record get created at all?
# WooCommerce → Status → Logs → filter by teamzlab_fedex_shippnig / teamz_shipment_create / teamz_fedex_checkout

# 3. Only if WP_DEBUG was on will full payloads be present.

Interpretation shortcuts:

Rate log present but no teamz_shipment_create entries → checkout never reached the Ship call (quota, pre-ship guard, or non-FedEx method — check the order notes).
teamz_shipment_create response shows error_code= → the failure is FedEx-side; the code maps to the errors array in the response.
The public rate widget (GET /fshipping/v1/rate-quote) intentionally logs nothing — its rate limiting and caching are documented in REST API.

Architecture

How the layers and the HTTP clients fit together.

Hooks & filters

Every filter and action, including the Open Ship log gates.

Options, quota & data model

Transient keys, TTLs, and the staging log option.

REST API

The public endpoints and their rate limits.

Getting Started

Settings Reference

Admin Pages

Shipping Workflows

Tracking & Returns

Developer Reference

Support

Where to read the logs

Active log sources

Detail level: `WP_DEBUG` gate

Declared-but-inactive sources

Open Ship logging surfaces

Staging-mode log

What is never logged

Order notes as the operational log

Using logs in support

Architecture

Hooks & filters

Options, quota & data model

REST API

​Where to read the logs

​Active log sources

​Detail level: WP_DEBUG gate

​Declared-but-inactive sources

​Open Ship logging surfaces

​Staging-mode log

​What is never logged

​Order notes as the operational log

​Using logs in support

Architecture

Hooks & filters

Options, quota & data model

REST API

Where to read the logs

Active log sources

Detail level: `WP_DEBUG` gate

Declared-but-inactive sources

Open Ship logging surfaces

Staging-mode log

What is never logged

Order notes as the operational log

Using logs in support