Download the PHP package badgerwise/wc-connect without Composer

wc-connect

Framework-agnostic WooCommerce REST API client for PHP, with first-class support for WordPress Application Password authentication. Drop it into any PHP project — Laravel, plain PHP, or a NativePHP mobile app.

• No enforced HTTP client. Codes against PSR-18/PSR-17 interfaces and auto-discovers whatever client your project already has (Laravel → Guzzle).
• Application Passwords first (WordPress 5.6+ core), so a mobile app can authenticate a user through the browser and never store their real password.
• WooCommerce consumer key/secret supported too.
• Typed resource helpers ($wc->orders(), ->products(), ->customers()) with pagination, on top of a generic get/post/put/delete client.

Requirements

• PHP 8.3+

• A PSR-18 HTTP client and PSR-17 factories in your project. Most already have one; if not:

  If none can be discovered, the constructor throws MissingHttpClientException with install suggestions.

Installation

Quick start

With a WordPress Application Password

Create one under Users → Profile → Application Passwords in wp-admin.

The spaces WordPress shows in the password are ignored — paste it as-is.

With WooCommerce consumer keys

Generate a key/secret under WooCommerce → Settings → Advanced → REST API.

Consumer keys are sent as HTTP Basic auth (HTTPS only). For a plain-HTTP dev store, pass them as query-string parameters instead:

The Application Password authorization flow (mobile / one-click)

Instead of asking users to generate a password by hand, send them through WordPress's built-in authorization screen. This is the recommended flow for a NativePHP mobile app: WordPress hands your app a scoped application password, and the user's real credentials never touch your code.

fromCallback() throws a WcConnectException if the user rejected the request or the credentials are missing (e.g. the store predates WordPress 5.6 or does not serve HTTPS).

Generic client

get, post, put, and delete all return the decoded JSON body as an array.

Need response headers (e.g. for pagination)? Use send(), which returns a Response (status code, headers, decoded body):

A different REST namespace

The default namespace is wc/v3. Pass another to hit core WordPress or other plugins:

Uploading a file to the Media Library

uploadMedia() posts a file to WordPress' Media Library (wp/v2/media) and returns the created media object — regardless of the client's namespace. Handy for attaching images/PDFs (e.g. a delivery photo) and then referencing the returned id / source_url from an order's meta_data.

The authenticated user needs the WordPress upload_files capability.

Resource helpers

Typed sugar over the generic client. Each helper exposes list, find, create, update, and delete.

Pagination

list() returns a PaginatedResult — iterable and countable — that also carries WooCommerce's X-WP-Total / X-WP-TotalPages metadata:

Walk every page:

Verifying incoming webhooks

WooCommerce can push events (new order, status change, …) to your app. Each delivery is signed as base64(HMAC-SHA256(rawBody, secret)) in the X-WC-Webhook-Signature header. Verify it against the raw request body before trusting the payload:

The check is timing-safe and returns false for an empty or mismatched signature. Use the exact bytes received (e.g. Laravel's $request->getContent()), not a re-encoded array, or the signature won't match.

Error handling

Every failure is a WcConnectException (extends RuntimeException), so a single catch covers transport errors, invalid JSON, and API errors.

A non-2xx API response throws ApiException, which exposes the WooCommerce error details:

Injecting your own HTTP client

Discovery is convenient, but you can pass everything explicitly — useful in tests or when you want a preconfigured client (timeouts, retries, logging):

Development

composer is not on PATH by default here; use Herd's binaries:

License

MIT