order.created webhook firing twice

More info again.

I have found the code that runs the ping, and the code that makes the delivery request, and compared them.

https://woocommerce.github.io/code-reference/files/woocommerce-includes-class-wc-webhook.html#source-view.603

	public function deliver_ping() {
		$args = array(
			'user-agent' => sprintf( 'WooCommerce/%s Hookshot (WordPress/%s)', Constants::get_constant( 'WC_VERSION' ), $GLOBALS['wp_version'] ),
			'body'       => 'webhook_id=' . $this->get_id(),
		);

		$test          = wp_safe_remote_post( $this->get_delivery_url(), $args );

^^^ does not add the additional headers.

Contrast with the correct approach in https://woocommerce.github.io/code-reference/files/woocommerce-includes-class-wc-webhook.html#source-view.343:

public function deliver( $arg ) {
	// SNIP
	
	// Setup request args.
	$http_args = array(
		// SNIP
	);

	$http_args = apply_filters( 'woocommerce_webhook_http_args', $http_args, $arg, $this->get_id() );

	// Add custom headers.
	// SNIP

	// Webhook away!
	$response = wp_safe_remote_request( $this->get_delivery_url(), $http_args );

Note how deliver calls apply_filters there. deliver_ping should be doing the same.

Can’t see how this isn’t just a bug?

I’ve had a look through the code and the docs for the CLI and API and can see nowhere that exposes pending_delivery as a settable. There’s a (couple of ~) set_pending_delivery methods and calls thereto, but it’s all internal stuff.

I’ll bodge this by hitting the DB directly.

Cheers for the response, Moses!

And, yeah, I get all that. I did actually even quote the part of the docs that explains it.

I suspect you have not actually seen my most recent response? I do explain what the story is, include relevant code etc.

But to summarise again:

It’s not the _emptiness of the body_ that is the issue. It’s the request doesn’t send all the headers _that I’ve configured it to_ when doing the ping. It’s not sending the auth. This makes it not a valid way to perform the test it’s trying to. I pointed out the bit of code and what’s missing.

Regarding this:

A practical way to handle both real and validation requests is to modify your webhook endpoint

I amn’t using WP on the other end, and also *simply letting any old unauthorised request through to my app* is not a great suggestion, security-wise. The security on the end point says “it needs to be a post, and it needs to have valid auth. Fullstop”. The request doesn’t even get to my controller method; the routing & security systems go “nuh-uh” well before that. This is how these things tend to work in 2025, I think? It’s not for the controller to deal with this stuff on an ad hoc basis.

I worked around it by updating the DB field when we first install the webhook. This is fine. If the webhook’s target _fails_ subsequently, we’ll get all the logging and alerts and stuff.

Done: https://github.com/woocommerce/woocommerce/issues/60886.