Add webform submit handler and push data to pardot on submission

+  /**
+   * Post data to pardot url.
+   *
+   * @param string $url
+   *   The pardot url string.
+   * @param array $data
+   *   The data array to be posted to pardot.
+   */
+  public function postDataToPardot($url, array $data);

I'm skeptical that that should be the public API for the service. I wouldn't know how to use that. What URL? What kind of data?

The implementation of this method, and PardotSubmissionQueue::processItem, indicates it should return something, but that's not described on the interface.

What it is returning is the response from Pardot, but that seems like it should remain the pardot handler service's problem, and the return value should be whatever the queue worker needs to know to decide how to manage the job (ie so the queue worker can tell if it is it done, if it it succeeded or failed, should it retry?).

+  /**
+   * {@inheritdoc}
+   */
+  public function submitForm(
+    array &$form,
+    FormStateInterface $form_state,
+    WebformSubmissionInterface $webform_submission
+  ) {
+    // Prepare data to send to the pardot.
+    $values['data'] = $webform_submission->getData();
+    $values['url'] = $this->configuration['pardot_url'];
+    $values['pardot_submission'] = $pardot_submission->id();
+
+    // Add data to queue.
+    $queue = $this->queueFactory->get('pardot_submission_queue');
+    $queue->createItem($values);
+  }

It looks like $pardot_submission has not been defined anywhere.

I'm not a fan of the queue having a copy of all that data, and not knowing about changes to it. What is a submission is edited or someone configured the wrong URL and had to fix it? I'd just put the ID of the submission in the queue and let the pardot service figure out the rest of this.

If PardotHandlerInterface took a webform submission as its argument instead of the destination and data, it would actually be doing something more than wrapping @http_client. Alternative implementations of the pardot handler service would have more freedom.

+ "homepage": "https://www.drupal.org/project/commerce_bluesnap",

Looks like that should be https://www.drupal.org/project/webform_pardot.

+/**
+ * Helper class with functions related to pardot form handler integration.
+ */
+class PardotHandler implements PardotHandlerInterface {

Most of that description is noise - don't bother saying it's a class, has functions, or is helpful. Removing those parts, the description doesn't say what the class is for. What about something like "Sends (data? form data?) to a Pardot form handler." Also see https://www.drupal.org/docs/develop/standards/api-documentation-and-comm....

+ * Interface for the service that prepares webform data submission to pardot.

PardotHandlerInterface is better (though I'm not sure you need to say it's an interface since that's in the name already. I suggest checking what Drupal core or Commerce write for their interfaces and using them as a guide.). It includes a third person verb in "Provides". Is that the right verb? It actually sends data, but prepares implies it just gets something ready.

+  /**
+   * Constructs a PardotSubmission object.
+   *
+   * @param \GuzzleHttp\ClientInterface $http_client
+   *   The Http client.
+   */
+  public function __construct(

That's in PardotHandler so the description is not correct.

Simiarly, PardotSubmission::__construct() says it constructs a WebformHandlerBase object. I'm not sure if that one should just use {@inheritdoc} or if it should have its own documentation.

+description: Module that sends webform submissions to pardot.

Don't bother calling it a module. Pardot is a proper noun so it should be capitalized.

+/**
+ * @file
+ * Contains hook functions related to webform_pardot module.
+ */

For .module file @file comments, describe the feature the module provides, not what module it's for (that's already known from the directory and file name). See https://www.drupal.org/docs/develop/standards/api-documentation-and-comm....

Have you planned for how to write tests for this process yet?

I'd just put the ID of the submission in the queue and let the pardot service figure out the rest of this.

Or, since #3090582: Log all activities associated with pardot submission creates an entity for Pardot submissions, the ID of the Pardot submission entity, not the Webform submission entity.

Looks good to me, Safallia. The interface is a lot cleaner now that it's getting the submission.