src/util.ts (1)

60-60: Export list is starting to grow – consider grouping or re-exporting

Nothing wrong functionally, but the flat export list is becoming long. A barrel file or grouped exports (e.g. export * as util from './util') would improve discoverability as the module grows.

src/index.ts (1)

111-114: Five nearly identical throttle initialisations – DRY it up

this.throttledSearchFetch ??= throttle(...); is now repeated for search/aiAnswers/suggestions/autocomplete/recommendation.
Extracting a tiny helper like:

private initThrottle(bucket: 'search' | 'ai' | 'suggest' | 'autocomplete' | 'recommend') {
  const delay = this.settings.getSettings().throttleTimeMs;
  if (!this[`throttled${bucket}`]) {
    this[`throttled${bucket}`] = throttle(delay, executeApiFetch);
  }
}

would remove duplication and lower the risk of future inconsistencies.

src/settings.ts (1)

99-101: Default value is uppercase 'GET' – keep the enum case-safe

Backend APIs are often case-sensitive. If the server later expects lowercase ('get'|'post'), compilation won’t catch it. Consider enforcing/lowering case when persisting:

this.settings.apiMethod = 'GET'; // ➜ 'get'

and annotate the union type accordingly.

src/apifetch.ts (2)

230-244: Duplicate custom-field keys silently overwrite values

Building customFieldFiltersValues with customFieldFiltersValues[customFieldName] = customFieldValue means the last duplicate key wins.
If multiple values per field are allowed (e.g. color=red, color=blue), consider storing an array per field instead.

---

490-505: apiMethod === 'POST' excludes recommend

Calling setApiMethod('POST') and then recommend() still performs a GET request.
Clarify intent in docs or extend support to avoid mixed semantics.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

src/apifetch.ts (2)

182-209: Comprehensive payload construction for search requests.

The POST payload construction covers all the necessary search parameters. However, there's still an issue with price parsing that was flagged in previous reviews.

The priceFromCents and priceToCents are still being parsed with parseFloat which can introduce floating-point inaccuracies since cents should be integers.

-      priceFromCents: settings?.priceFromCents ? parseFloat(settings?.priceFromCents) : undefined,
-      priceToCents: settings?.priceToCents ? parseFloat(settings?.priceToCents) : undefined,
+      priceFromCents: settings?.priceFromCents ? parseInt(settings?.priceFromCents, 10) : undefined,
+      priceToCents: settings?.priceToCents ? parseInt(settings?.priceToCents, 10) : undefined,

---

452-505: ⚠️ Potential issue

Critical issues remain unresolved in request handling.

The conditional POST/GET request handling is well-structured, but two critical issues from previous reviews persist:

1. URI decoding issue: The POST flow blindly calls decodeURIComponent(keyword) without checking if the keyword was URI-encoded, which can cause URIError for special characters.

2. Missing parameters in fuzzy retry: The recursive call omits customFilterObject and recommendOptions.

Apply these fixes:

    if (settings?.apiMethod === 'POST' && ['search', 'suggest', 'autocomplete'].includes(type)) {
      apiEndpoint = 'https://' + apiHostname + '/v1/' + apiPath + '/' + sitekey;
+     const term = type === 'search' ? decodeURIComponent(keyword) : keyword;
      requestPayloadObject = {
-       term: decodeURIComponent(keyword),
+       term: term,
        ...requestPayloadObject
      };
      apiInstance
        .post(apiEndpoint, requestPayloadObject)
        .then(handleApiResponse)
        .catch(handleApiError);
    } else {

And fix the fuzzy retry call:

-        executeApiFetch(apiHostname, sitekey, type, settings, cb, true);
+        executeApiFetch(
+          apiHostname,
+          sitekey,
+          type,
+          settings,
+          cb,
+          true,
+          customFilterObject,
+          recommendOptions
+        );

README.md (1)

535-543: Fix heading level and approve documentation addition.

The new POST API documentation is helpful and clearly explains the new functionality. However, there's a heading level issue to fix.

Apply this diff to fix the heading level issue:

-#### Fetch AI answers
+### Fetch AI answers

The content effectively documents the new setApiMethod('POST') functionality and appropriately warns users about limited support.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

538-538: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4

(MD001, heading-increment)

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

src/apifetch.ts (1)

458-465: ⚠️ Potential issue

Recursive fuzzy retry still loses extra parameters
See previous review – issue remains.

customFilterObject and recommendOptions are not forwarded in the retry call, so the second request can differ from the first one.

-executeApiFetch(apiHostname, sitekey, type, settings, cb, true);
+executeApiFetch(
+  apiHostname,
+  sitekey,
+  type,
+  settings,
+  cb,
+  true,
+  customFilterObject,
+  recommendOptions
+);

src/settings.ts (1)

69-73: Why keep apiMethod optional if you always initialise it?

apiMethod is declared as apiMethod?: ApiMethod; yet the constructor always sets a default ('GET').
Making the field non-optional (apiMethod: ApiMethod;) tightens the type system and removes the need for defensive undefined checks elsewhere.

-  apiMethod?: ApiMethod;
+  apiMethod: ApiMethod;

src/apifetch.ts (1)

188-189: Boolean → string conversion for fuzzy may surprise callers

JSON.stringify(true) results in the string "true", whereas the GET version sends fuzzy=true (string as well).
If the backend accepts raw booleans in JSON, consider passing the value unmodified:

-  fuzzy: fuzzy !== true && fuzzy !== false ? fuzzy : JSON.stringify(fuzzy),
+  fuzzy,

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro