Developers

StitchPress is extended through WordPress actions and filters. Every hook name starts with stp_. Where a setting and a filter cover the same value, the settings screen hooks that filter at the default priority (10). Hook the same filter at priority 11 or higher and your value wins over the setting.

Hooks and filters

Arguments are listed in order. "Action" means do_action, everything else is a filter.

Extension points

Templates and methods

Pricing and setup fees

Designer and cart

Uploads and artwork

Palettes and fonts

Production estimates

Previews

Proofs

Job Jacket and production queue

Skins

The full map, including names reserved for upcoming features, is includes/hooks.php in the plugin source.

Hooks added in 1.0.0: stp_settings_export_keys, stp_status_checks, stp_wizard_steps, stp_bulk_assign_done, stp_production_statuses, stp_production_status_changed, stp_webhook_topics, stp_reorder_record, stp_export_columns, stp_variation_view_image, stp_design_saved, stp_privacy_data, stp_retention_days, stp_license_status, stp_demo_created. Arguments are documented in includes/hooks.php.

Events

STP_Log::event( $name, $context ) fires the stp_event action with an event name and a context array of IDs and states, never customer text. Listen to it for webhooks, integrations or your own logging:

add_action( 'stp_event', function ( $name, $context ) {
    if ( 'proof.approved' === $name ) {
        // $context['order_id'], $context['round']
    }
}, 10, 2 );

Event names are listed in includes/hooks.php (design.ordered, proof.sent, proof.approved, proof.changes_requested, production.status_changed, design.saved, upload.rejected, settings.imported, privacy.erased, license.changed). In this build the proof workflow fires its own actions (stp_proof_sent, stp_proof_approved, stp_proof_changes_requested); use those until the events are wired.

REST API

All StitchPress routes live under one namespace, stitchpress/v1. Routes are added through the stp_rest_routes filter, not by calling register_rest_route() directly:

add_filter( 'stp_rest_routes', function ( $routes ) {
    $routes[] = array(
        'route' => '/orders/(?P<id>\d+)/designs',
        'args'  => array(
            'methods'             => 'GET',
            'callback'            => 'my_designs_callback',
            'permission_callback' => function () {
                return current_user_can( 'manage_woocommerce' );
            },
        ),
    );
    return $routes;
} );

args may be one endpoint array or a list of them, as WordPress accepts. A route without a permission_callback is refused and logged as an error, so a forgotten capability check cannot ship. A public route must say so explicitly with '__return_true' and do its own nonce and rate-limit checks.

StitchPress's own routes need manage_woocommerce (an application password or a WooCommerce REST API key of a user who has it; 401 or 403 otherwise):

• GET /orders: decorated orders, newest first. Arguments status, production_status, after (date-time), page, per_page (up to 100). The X-WP-Total and X-WP-TotalPages headers count every matching order. Decorated orders are found by reading orders newest first, at most 10,000 for one page (filter stp_rest_orders_scan_limit); when that limit stops a page before it is full, the response has the header X-STP-Truncated: true. Narrow the request with after or status and ask again.
• GET /orders/<id>: the order document (lines with their design records, proof state, production status and history).
• GET /orders/<id>/designs: the design record of each decorated line, keyed by line id.
• GET /orders/<id>/sheet: the production sheet HTML.
• POST /orders/<id>/production: set the production status (status).

Webhooks

Three WooCommerce webhook topics: stitchpress.design_ordered (a decorated order is paid, once per order), stitchpress.proof_approved and stitchpress.production_status. Add them under WooCommerce > Settings > Advanced > Webhooks like any WooCommerce webhook; the secret, the X-WC-Webhook-Signature header (base64 of HMAC-SHA256 of the body with the secret) and the delivery log are WooCommerce's.

The body is the document GET /stitchpress/v1/orders/<id> returns, plus three fields:

• event: the topic.
• event_id: a UUID (v4) for this event. It is the same on every retry of the event, so store it and skip a body whose event_id you have already processed. WooCommerce's X-WC-Webhook-Delivery-ID header changes on every attempt and is not a de-duplication key.
• occurred_at: when the event happened, in UTC (2026-10-07T14:03:00Z), not when this attempt was sent.

Retries. WooCommerce sends each delivery once. When one of these topics gets a connection error or a status outside 200 to 299, StitchPress sends it again after 1, 5 and 30 minutes (filter stp_webhook_retry_delays), then logs that it gave up.

WooCommerce disables a failing webhook. Every failed attempt, retries included, adds one to the webhook's failure count; a success (status 200 to 302) resets it to zero. When a delivery fails while the count is already above 5 (filter woocommerce_max_webhook_delivery_failures), WooCommerce sets the webhook to Disabled. One event that fails every attempt counts 4 failures, so two such events in a row disable the webhook, and StitchPress does not retry for a disabled webhook. Re-enabling it in the settings does not reset the count, so the next failure disables it again until one delivery succeeds. Keep your endpoint answering 2xx quickly and do the work after replying.

Logging

StitchPress logs through WooCommerce's logger with the source stitchpress. Read the logs under WooCommerce > Status > Logs and pick a stitchpress file (or source).

• Errors and warnings are always written.
• Debug lines are written only when Debug log is on (StitchPress settings > Advanced) or when stp_log_debug_enabled returns true. Leave it off unless support asks for it.
• Anything that looks like an email address is masked as [email] before a line is written.

From your own code:

STP_Log::warning( 'Something to look at', array( 'order_id' => 123 ) );

STP_Log has debug(), info(), warning(), error() and event(). Pass IDs and states in the context array, not customer text.

Template overrides

StitchPress renders its storefront, proof page and Job Jacket markup in PHP, not from template files, so there is nothing to copy into your theme in this build. Change output with the filters above (stp_sheet_render_item, stp_sheet_css, stp_proof_email_body and so on) and the look of the designer with a skin.

The override folder is reserved: templates that StitchPress renders through STP_Email_Registry::render() are looked up first in wp-content/themes/<your-theme>/stitchpress/, then in the plugin's templates/ folder, the same way WooCommerce template overrides work.

Email templates ship under templates/emails/ as an HTML and a plain-text file per email; copy one to <your-theme>/stitchpress/emails/ with the same file name to override it.

Product setup

Products that arrive by import, REST or a feed plugin are set up at the end of the request (see Set up a product for decoration).

• do_action( 'stp_setup_product', $product_id ) queues a product from your own importer.
• stp_setup_should_run (filter, bool $run, int $product_id, string $source) skips products.
• stp_setup_result (filter, array $report, WC_Product $product, array $args) changes what is written, or returns a WP_Error to stop.
• stp_setup_done (action, int $product_id, array $report) runs after each setup.
• STP_Product_Setup::run( $product_id, array( 'dry' => true ) ) returns the report without writing.
• REST: GET and POST stitchpress/v1/products/<id>/setup (dry, force), for users who can manage WooCommerce and edit that product.

Product meta: _stp_decorate (yes or no), _stp_product_views (view key to attachment ID), _stp_setup (the last report).

Adding a module

Code that ships inside StitchPress is organised as modules: a file includes/admin/, includes/commerce/ or includes/release/ named class-stp-<name>.php, defining STP_<Name> with a public static function register(). StitchPress loads every module on plugins_loaded after its core has started. This is for StitchPress itself; for site-specific changes, use the hooks above from your theme or a small plugin.

Related

• Skins
• Emails
• Methods and pricing
• Troubleshooting
• Privacy