Reviewing files that changed from the base of the PR and between 87661e9 and 34ea8bb.

• src/appmixer/stripe/auth.js (1 hunks)
• src/appmixer/stripe/bundle.json (1 hunks)
• src/appmixer/stripe/core/CancelPaymentIntent/CancelPaymentIntent.js (1 hunks)
• src/appmixer/stripe/core/CancelPaymentIntent/component.json (1 hunks)
• src/appmixer/stripe/core/CapturePaymentIntent/CapturePaymentIntent.js (1 hunks)
• src/appmixer/stripe/core/CapturePaymentIntent/component.json (1 hunks)
• src/appmixer/stripe/core/ConfirmPaymentIntent/ConfirmPaymentIntent.js (1 hunks)
• src/appmixer/stripe/core/ConfirmPaymentIntent/component.json (1 hunks)
• src/appmixer/stripe/core/CreateCustomer/CreateCustomer.js (1 hunks)
• src/appmixer/stripe/core/CreateCustomer/component.json (1 hunks)
• src/appmixer/stripe/core/CreateInvoice/CreateInvoice.js (1 hunks)
• src/appmixer/stripe/core/CreateInvoice/component.json (1 hunks)
• src/appmixer/stripe/core/CreatePaymentIntent/CreatePaymentIntent.js (1 hunks)
• src/appmixer/stripe/core/CreatePaymentIntent/component.json (1 hunks)
• src/appmixer/stripe/core/CreateRefund/CreateRefund.js (1 hunks)
• src/appmixer/stripe/core/CreateRefund/component.json (1 hunks)
• src/appmixer/stripe/core/DeleteCustomer/DeleteCustomer.js (1 hunks)
• src/appmixer/stripe/core/DeleteCustomer/component.json (1 hunks)
• src/appmixer/stripe/core/FinalizeDraftInvoice/FinalizeDraftInvoice.js (1 hunks)
• src/appmixer/stripe/core/FinalizeDraftInvoice/component.json (1 hunks)
• src/appmixer/stripe/core/FindCharges/FindCharges.js (1 hunks)
• src/appmixer/stripe/core/FindCharges/component.json (1 hunks)
• src/appmixer/stripe/core/FindPaymentMethods/FindPaymentMethods.js (1 hunks)
• src/appmixer/stripe/core/FindPaymentMethods/component.json (1 hunks)
• src/appmixer/stripe/core/FindRefunds/FindRefunds.js (1 hunks)
• src/appmixer/stripe/core/FindRefunds/component.json (1 hunks)
• src/appmixer/stripe/core/MakeAPICall/MakeAPICall.js (1 hunks)
• src/appmixer/stripe/core/MakeAPICall/component.json (1 hunks)
• src/appmixer/stripe/core/RetrieveCustomer/RetrieveCustomer.js (1 hunks)
• src/appmixer/stripe/core/RetrieveCustomer/component.json (1 hunks)
• src/appmixer/stripe/core/RetrieveInvoice/RetrieveInvoice.js (1 hunks)
• src/appmixer/stripe/core/RetrieveInvoice/component.json (1 hunks)
• src/appmixer/stripe/core/RetrievePaymentIntent/RetrievePaymentIntent.js (1 hunks)
• src/appmixer/stripe/core/RetrievePaymentIntent/component.json (1 hunks)
• src/appmixer/stripe/core/RetrieveRefund/RetrieveRefund.js (1 hunks)
• src/appmixer/stripe/core/RetrieveRefund/component.json (1 hunks)
• src/appmixer/stripe/core/SearchCustomers/SearchCustomers.js (1 hunks)
• src/appmixer/stripe/core/SearchCustomers/component.json (1 hunks)
• src/appmixer/stripe/core/SearchInvoices/SearchInvoices.js (1 hunks)
• src/appmixer/stripe/core/SearchInvoices/component.json (1 hunks)
• src/appmixer/stripe/core/SearchPaymentIntent/SearchPaymentIntent.js (1 hunks)
• src/appmixer/stripe/core/SearchPaymentIntent/component.json (1 hunks)
• src/appmixer/stripe/core/UpdateCustomer/UpdateCustomer.js (1 hunks)
• src/appmixer/stripe/core/UpdateCustomer/component.json (1 hunks)
• src/appmixer/stripe/lib.generated.js (1 hunks)
• src/appmixer/stripe/quota.js (1 hunks)
• src/appmixer/stripe/service.json (1 hunks)

src/appmixer/stripe/quota.js (2)

1-1: "use strict" directive is correct per coding guidelines.

The static analysis tool flagged this as redundant, but the coding guidelines explicitly state that "use strict" is desirable for src/appmixer/**/*.js files. Keep the directive as it aligns with project standards.

---

5-12: Rate limiting configuration looks appropriate.

The 5 requests per second limit with FIFO queueing is reasonable for Stripe API usage and aligns with typical rate limiting best practices.

src/appmixer/stripe/lib.generated.js (2)

14-22: Good error handling for empty records.

The check for empty records when outputType is 'first' prevents runtime errors and provides clear feedback.

---

52-54: Excellent use of optional chaining for safe property access.

The getProperty function uses optional chaining correctly to prevent errors when accessing nested properties.

src/appmixer/stripe/bundle.json (1)

1-9: Bundle configuration is correct.

The version "1.0.0" properly matches the last entry in the changelog, satisfying the coding guidelines requirement.

src/appmixer/stripe/core/CancelPaymentIntent/CancelPaymentIntent.js (2)

1-1: "use strict" directive is correct per coding guidelines.

As with other files, the static analysis tool flagged this as redundant, but the coding guidelines explicitly state that "use strict" is desirable for src/appmixer/**/*.js files.

---

9-16: HTTP request implementation looks correct.

The API call follows Stripe's documentation correctly with proper authentication headers and endpoint.

src/appmixer/stripe/core/FinalizeDraftInvoice/FinalizeDraftInvoice.js (3)

1-1: "use strict" directive is correct per coding guidelines.

Consistent with project standards for src/appmixer/**/*.js files.

---

6-6: Good use of destructuring for parameter extraction.

The destructuring approach for extracting invoiceId is clean and readable.

---

9-16: API request implementation is correct.

The HTTP request follows Stripe's API documentation correctly for finalizing invoices.

src/appmixer/stripe/core/RetrieveCustomer/RetrieveCustomer.js (1)

4-21: LGTM! Proper Stripe API integration implementation.

The module correctly implements the customer retrieval functionality with proper authentication, HTTP method, and response handling.

src/appmixer/stripe/core/CreatePaymentIntent/CreatePaymentIntent.js (1)

1-27: LGTM! Solid payment intent creation implementation.

The module correctly implements payment intent creation with proper HTTP method, authentication, data serialization, and response handling.

src/appmixer/stripe/core/RetrievePaymentIntent/RetrievePaymentIntent.js (1)

4-21: LGTM! Proper payment intent retrieval implementation.

The module correctly implements the payment intent retrieval functionality with appropriate API endpoint, authentication, and response handling.

src/appmixer/stripe/core/RetrieveInvoice/RetrieveInvoice.js (1)

4-21: LGTM! Proper invoice retrieval implementation.

The module correctly implements the invoice retrieval functionality with appropriate Stripe API endpoint, authentication, and response handling.

src/appmixer/stripe/core/RetrieveRefund/RetrieveRefund.js (1)

1-20: LGTM! Excellent refund retrieval implementation.

The module correctly implements the refund retrieval functionality with proper formatting, appropriate Stripe API endpoint, authentication, and response handling. This file serves as a good example with clean formatting.

src/appmixer/stripe/core/DeleteCustomer/DeleteCustomer.js (1)

8-21: LGTM! Clean Stripe customer deletion implementation.

The logic correctly extracts the customer ID, makes an authenticated DELETE request to the Stripe API, and returns the response data. The implementation follows Stripe's API documentation and matches the established patterns in this integration.

src/appmixer/stripe/core/CreateRefund/CreateRefund.js (1)

8-27: LGTM! Robust refund creation implementation.

The implementation correctly handles optional parameters by conditionally including them in the form data only when they have valid values. The thorough validation for amount (checking both undefined and empty string) is particularly good practice. The Stripe API call follows proper authentication patterns.

src/appmixer/stripe/core/CreateCustomer/CreateCustomer.js (1)

65-84: LGTM! Well-structured customer creation logic.

The core implementation correctly handles the complex customer creation scenario with conditional address and shipping information. The spread operator usage for conditionally including address and shipping objects is clean and effective.

src/appmixer/stripe/core/CreateInvoice/CreateInvoice.js (1)

8-28: LGTM! Proper invoice creation with field validation.

The implementation correctly handles optional invoice parameters with thorough validation (checking both undefined and empty string). The transformation from camelCase JavaScript variables to snake_case Stripe API fields (collectionMethod → collection_method, autoAdvance → auto_advance) is appropriate for API compatibility.

src/appmixer/stripe/core/MakeAPICall/MakeAPICall.js (1)

7-23: LGTM! Flexible API call implementation with security consideration.

The generic API call functionality is well-implemented and provides good flexibility. The customEndpoint parameter is directly interpolated into the URL, which is acceptable within the authenticated Appmixer context, but ensure that upstream validation prevents any potential path traversal or injection attacks.

Consider verifying that the component definition properly validates the customEndpoint parameter to prevent potential security issues.

src/appmixer/stripe/service.json (1)

1-8: Well-structured service configuration.

The JSON service descriptor is properly formatted and contains all necessary metadata fields for the Stripe integration. The service definition includes appropriate categorization and version information.

src/appmixer/stripe/core/ConfirmPaymentIntent/ConfirmPaymentIntent.js (2)

1-1: Keep the "use strict" directive as per coding guidelines.

The static analysis tool suggests removing "use strict", but the coding guidelines explicitly state that this directive is desirable for src/appmixer/**/*.js files. The guidelines take precedence over the static analysis suggestion.

---

4-26: Solid implementation of payment intent confirmation.

The function correctly handles the required payment_intent_id and optional payment_method parameters, constructs the request payload appropriately, and makes the authenticated API call to Stripe. The response handling is clean and follows the expected pattern.

src/appmixer/stripe/core/CapturePaymentIntent/CapturePaymentIntent.js (3)

1-1: Keep the "use strict" directive as per coding guidelines.

The static analysis tool suggests removing "use strict", but the coding guidelines explicitly state that this directive is desirable for src/appmixer/**/*.js files.

---

11-13: Appropriate conditional logic for optional amount parameter.

The condition correctly checks for both empty string and undefined values before including the amount_to_capture parameter, which aligns with Stripe's API expectations where this field is optional.

---

4-27: Well-implemented payment intent capture functionality.

The function properly extracts the required payment intent ID and optional amount, constructs the request data conditionally, and makes the authenticated API call to Stripe's capture endpoint. The implementation follows established patterns and handles the API response appropriately.

src/appmixer/stripe/core/SearchInvoices/SearchInvoices.js (5)

1-1: Keep the "use strict" directive as per coding guidelines.

The static analysis tool suggests removing "use strict", but the coding guidelines explicitly state that this directive is desirable for src/appmixer/**/*.js files.

---

5-26: Comprehensive and well-typed invoice schema definition.

The schema covers essential invoice fields with appropriate types, including nullable fields for optional data like customer_email and hosted_invoice_url. The field titles are descriptive and user-friendly.

---

32-37: Clean handling of output port options generation.

The conditional check for generateOutputPortOptions properly delegates to the library function with the correct schema and default port configuration.

---

40-51: Appropriate Stripe API integration for invoice search.

The GET request to the search endpoint includes proper authentication, query parameters, and a reasonable default limit of 100 results. The API URL and parameters align with Stripe's documentation.

---

53-58: Consistent array output handling.

The use of lib.sendArrayOutput with the data records and output type configuration ensures consistent response formatting across the Stripe integration.

src/appmixer/stripe/core/UpdateCustomer/UpdateCustomer.js (5)

1-1: Keep the "use strict" directive as per coding guidelines.

The static analysis tool suggests removing "use strict", but the coding guidelines explicitly state that this directive is desirable for src/appmixer/**/*.js files.

---

28-41: Elegant conditional address object construction.

The logic correctly builds the address object only when relevant fields are present, avoiding sending empty or null address data to the Stripe API. This approach is more efficient and cleaner than always including the address object.

---

43-62: Well-structured shipping object with nested address.

The conditional shipping object construction properly handles both shipping contact details and nested address information, following Stripe's expected data structure for shipping information.

---

77-78: Clean use of spread operator for conditional object inclusion.

The spread operator syntax elegantly includes the address and shipping objects only when they exist, resulting in clean request payloads without unnecessary null or undefined fields.

---

64-84: Robust customer update implementation.

The function comprehensively handles customer data updates including contact details, billing address, and shipping information. The API call structure is correct with proper authentication and the response handling follows established patterns.

src/appmixer/stripe/core/FindCharges/FindCharges.js (1)

1-2: 'use strict' directive is appropriate here.

The static analysis tool flagged this as redundant, but according to the coding guidelines for src/appmixer/**/*.js files, the directive "use strict"; is desirable here.

src/appmixer/stripe/auth.js (1)

1-1: 'use strict' directive is appropriate here.

The static analysis tool flagged this as redundant, but according to the coding guidelines for src/appmixer/**/*.js files, the directive "use strict"; is desirable here.

src/appmixer/stripe/core/SearchPaymentIntent/SearchPaymentIntent.js (2)

1-51: Implementation looks correct.

The module correctly implements payment intent search functionality with proper API endpoint, schema definition, and output handling. The code follows the established patterns for the Stripe integration.

---

1-1: 'use strict' directive is appropriate here.

The static analysis tool flagged this as redundant, but according to the coding guidelines for src/appmixer/**/*.js files, the directive "use strict"; is desirable here.

src/appmixer/stripe/core/SearchCustomers/SearchCustomers.js (2)

5-67: Implementation looks correct.

The module correctly implements customer search functionality with a comprehensive schema that includes all relevant customer fields and the nested address object. The API endpoint and output handling are properly implemented.

---

1-1: 'use strict' directive is appropriate here.

The static analysis tool flagged this as redundant, but according to the coding guidelines for src/appmixer/**/*.js files, the directive "use strict"; is desirable here.

src/appmixer/stripe/core/FinalizeDraftInvoice/component.json (1)

1-66: LGTM! Well-structured component configuration.

The component definition follows the established patterns correctly with proper input validation, authentication setup, quota management, and clear inspector metadata for user guidance.

src/appmixer/stripe/core/FindRefunds/FindRefunds.js (1)

7-34: LGTM! Well-implemented Stripe API integration.

The module correctly handles parameter extraction, API authentication, request formation, and output formatting. The logic follows the established patterns for Stripe components.

src/appmixer/stripe/core/SearchCustomers/component.json (1)

1-85: LGTM! Comprehensive customer search component configuration.

The configuration properly defines input validation, dynamic output port generation, multiple output format options, and clear UI metadata. The authentication and quota management are correctly configured.

src/appmixer/stripe/core/MakeAPICall/component.json (1)

14-80: LGTM! Flexible API call component design.

The component provides a clean interface for arbitrary Stripe API calls with proper parameter handling and multiple output options (aside from the naming inconsistency noted above).

src/appmixer/stripe/core/FindPaymentMethods/FindPaymentMethods.js (1)

5-62: LGTM! Comprehensive payment methods integration.

The module provides a well-structured schema definition for payment method objects and implements proper API interaction patterns. The parameter handling and output formatting are consistent with other Stripe components.

src/appmixer/stripe/core/RetrieveRefund/component.json (3)

1-13: Top-level metadata looks correct
Component name, version, auth and quota settings align with other Stripe core components.

---

14-38: Input port schema is valid
The inPorts block correctly enforces a required refundId string and provides proper inspector metadata.

---

40-59: Basic output port options are defined properly
The scalar fields id, object, amount, etc. are exposed with correct types.

src/appmixer/stripe/core/RetrievePaymentIntent/component.json (2)

1-13: Top-level metadata alignment
Name, version, auth, and quota sections match other retrieve components.

---

14-38: Input port uses consistent camelCase
The paymentIntentId property aligns with naming in other components.

src/appmixer/stripe/core/CancelPaymentIntent/component.json (1)

1-13: Metadata is correct
Component name, description, auth, and quota settings are in line with the PR’s standards.

src/appmixer/stripe/core/SearchInvoices/component.json (3)

1-13: Component definition is sound
Name, auth, version, and quota settings mirror the pattern of other search components.

---

14-39: Input port configuration is complete
query is required, outputType is optional with correct default and options.

---

69-83: Dynamic output port mapping is correct
Using a source URL with generateOutputPortOptions follows the established dynamic pattern.

src/appmixer/stripe/core/CreateRefund/component.json (2)

1-13: Metadata definitions are accurate
Component metadata is consistent with other Create* components.

---

56-90: Output port options are well-defined
Exposes id, object, amount, and status as expected.

src/appmixer/stripe/core/DeleteCustomer/component.json (3)

1-5: Metadata looks correct.
Good component naming, versioning, and description.

---

7-13: Auth and quota configuration is consistent.
The auth.service and quota.manager correctly reference appmixer:stripe.

---

37-63: Output port schema is correct.
The options for id, object, and deleted are well defined.

src/appmixer/stripe/core/CapturePaymentIntent/component.json (2)

1-6: Component metadata is well defined.
Name, description, and version follow the established pattern.

---

50-74: Output port options are accurate.
Exposing id, object, and status aligns with response fields.

src/appmixer/stripe/core/CreateInvoice/component.json (1)

69-97: Output port schema is consistent.
Fields id, object, customer, and status are correctly defined.

src/appmixer/stripe/core/UpdateCustomer/component.json (3)

1-13: Metadata, auth, and quota are correct.
Component name, version, auth, and quota align with standards.

---

14-84: Input schema is comprehensive and correctly required.
All optional fields are defined and only customerId is marked as required.

---

211-238: Output port options are appropriate.
Exposing id, object, and email matches the update response.

src/appmixer/stripe/core/SearchPaymentIntent/component.json (1)

69-83: Dynamic outPort mapping is well configured.
The generateOutputPortOptions and message mappings are correct.

src/appmixer/stripe/core/RetrieveInvoice/component.json (1)

198-202: Fix custom_fields schema.

Invoice custom_fields is an array of objects, not a string. Change schema to:

-"type": "string"
+"type": "array",
+"items": { "type": "object", /* custom field props */ }

Likely an incorrect or invalid review comment.

Reviewing files that changed from the base of the PR and between 34ea8bb and 08872b6.

• src/appmixer/stripe/auth.js (1 hunks)
• src/appmixer/stripe/core/ConfirmPaymentIntent/ConfirmPaymentIntent.js (1 hunks)
• src/appmixer/stripe/core/CreateCustomer/CreateCustomer.js (1 hunks)
• src/appmixer/stripe/core/CreateCustomer/component.json (1 hunks)
• src/appmixer/stripe/core/CreateInvoice/CreateInvoice.js (1 hunks)
• src/appmixer/stripe/core/CreateRefund/CreateRefund.js (1 hunks)
• src/appmixer/stripe/core/DeleteCustomer/DeleteCustomer.js (1 hunks)
• src/appmixer/stripe/core/FindCharges/FindCharges.js (1 hunks)
• src/appmixer/stripe/core/RetrieveCustomer/component.json (1 hunks)
• src/appmixer/stripe/core/RetrieveInvoice/component.json (1 hunks)

• src/appmixer/stripe/core/CreateCustomer/component.json
• src/appmixer/stripe/core/RetrieveCustomer/component.json
• src/appmixer/stripe/core/RetrieveInvoice/component.json

src/appmixer/stripe/core/CreateRefund/CreateRefund.js (1)

11-11: Fix amount validation to handle zero values correctly.

The current validation amount !== undefined && amount !== '' will exclude valid zero amounts. Zero is a legitimate refund amount in Stripe.

-        if (amount !== undefined && amount !== '') formData.amount = amount;
+        if (amount !== undefined && amount !== null && amount !== '') {
+            const numericAmount = parseInt(amount, 10);
+            if (!isNaN(numericAmount) && numericAmount >= 0) {
+                formData.amount = numericAmount;
+            }
+        }

Likely an incorrect or invalid review comment.

src/appmixer/stripe/core/DeleteCustomer/DeleteCustomer.js (2)

1-1: 'use strict' directive conflicts with static analysis.

The static analysis tool flags this as redundant since JavaScript modules are automatically in strict mode. However, your coding guidelines specify that this directive is "desirable" for src/appmixer/**/*.js files. Consider clarifying the coding guidelines to resolve this conflict.

---

9-18: API call implementation looks correct.

The HTTP DELETE request is properly structured with correct headers, authentication, and response handling. The use of application/x-www-form-urlencoded content type is appropriate for Stripe API calls.

src/appmixer/stripe/core/CreateCustomer/CreateCustomer.js (5)

5-25: Input parameter destructuring is comprehensive.

Good coverage of all customer-related fields including billing and shipping address components. The destructuring approach is clean and maintainable.

---

27-40: Address object construction logic is correct.

The conditional logic properly checks for any address field presence before creating the address object. This prevents sending empty address objects to the Stripe API.

---

42-61: Shipping object construction follows good pattern.

The conditional logic mirrors the address construction pattern and properly nests the shipping address within the shipping object, matching Stripe's API expectations.

---

70-78: Excellent use of conditional spread operator.

The spread operator usage ...(address && { address }) and ...(shipping && { shipping }) elegantly handles optional fields without cluttering the data object with undefined values.

---

63-81: API call implementation is well-structured.

The HTTP POST request properly formats the data, uses correct authentication, and handles the response appropriately. The parameter mapping (e.g., paymentMethod to payment_method) follows Stripe's API conventions.

Reviewing files that changed from the base of the PR and between 08872b6 and 2883510.

• src/appmixer/stripe/core/CreateInvoice/component.json (1 hunks)
• src/appmixer/stripe/core/DeleteCustomer/component.json (1 hunks)
• src/appmixer/stripe/core/FindCharges/component.json (1 hunks)
• src/appmixer/stripe/core/MakeAPICall/component.json (1 hunks)
• src/appmixer/stripe/core/RetrievePaymentIntent/component.json (1 hunks)

• src/appmixer/stripe/core/FindCharges/component.json

• src/appmixer/stripe/core/RetrievePaymentIntent/component.json
• src/appmixer/stripe/core/DeleteCustomer/component.json
• src/appmixer/stripe/core/MakeAPICall/component.json

src/appmixer/stripe/core/CreateInvoice/component.json (4)

1-6: Approve metadata and component definition.
The name, author, description, and version fields follow conventions and align with the integration’s naming scheme.

---

7-13: Approve auth and quota configuration.
The component correctly references the Stripe auth service and enforces request quotas as expected.

---

43-71: Approve inspector metadata.
The input port inspector configuration is clear and provides appropriate labels, tooltips, indexes, and default values.

---

75-107: Approve output port definitions.
The outPorts correctly expose id, object, customer, and status with accurate schemas and labels.

Reviewing files that changed from the base of the PR and between 9a5898b and be5900d.

• src/appmixer/stripe/core/FindCustomers/FindCustomers.js (1 hunks)
• src/appmixer/stripe/core/FindCustomers/component.json (1 hunks)
• src/appmixer/stripe/core/FindInvoices/FindInvoices.js (1 hunks)
• src/appmixer/stripe/core/FindInvoices/component.json (1 hunks)
• src/appmixer/stripe/core/FindPaymentIntent/FindPaymentIntent.js (1 hunks)
• src/appmixer/stripe/core/FindPaymentIntent/component.json (1 hunks)

• src/appmixer/stripe/core/FindCustomers/component.json
• src/appmixer/stripe/core/FindPaymentIntent/component.json
• src/appmixer/stripe/core/FindInvoices/component.json

src/appmixer/stripe/core/FindCustomers/FindCustomers.js (2)

5-33: Well-structured schema definition.

The schema comprehensively covers Stripe customer properties with appropriate types and nullable fields. Good use of nested object structure for the address field.

---

35-67: Solid implementation following Appmixer patterns.

The receive function correctly:

• Handles output port options generation
• Makes authenticated HTTP requests to Stripe API
• Uses proper error handling (letting the engine handle exceptions)
• Leverages the generated library for consistent output formatting

The API call follows Stripe's documentation and includes appropriate headers and parameters.

src/appmixer/stripe/core/FindInvoices/FindInvoices.js (3)

5-26: Well-structured invoice schema definition.

The schema comprehensively covers the essential invoice fields from Stripe's API, including financial details, customer information, and metadata. The field types and titles are appropriate for the invoice data structure.

---

28-60: Solid implementation following established patterns.

The implementation correctly follows the pattern established by other Stripe search modules in the codebase:

• Proper handling of output port options generation
• Correct API endpoint usage (/v1/invoices/search)
• Appropriate authorization headers and query parameters
• Consistent use of lib.sendArrayOutput for response handling

The 100-item limit is reasonable for search operations and matches other modules.

---

1-1: Remove redundant 'use strict' directive.

Static analysis correctly identifies that the 'use strict' directive is redundant in ES6 modules, as they are automatically in strict mode.

-'use strict';

⛔ Skipped due to learnings

Learnt from: CR
PR: clientIO/appmixer-connectors#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T09:09:52.832Z
Learning: Applies to test/utils.js : Use `test/utils.js` for Appmixer stub.

Learnt from: CR
PR: clientIO/appmixer-connectors#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-06-30T09:09:52.832Z
Learning: Applies to src/appmixer/*/core/*/*.js : Do not check for required properties in the `receive` function of behavior files; required properties are validated by the input schema in component.json.

src/appmixer/stripe/core/FindPaymentIntent/FindPaymentIntent.js (4)

3-17: Well-structured schema definition.

The import statement and schema definition are properly implemented. The schema comprehensively covers the essential payment intent fields with appropriate types and descriptive titles.

---

19-28: Correct implementation of output port options generation.

The receive function and generateOutputPortOptions handling follow the established pattern correctly. The parameter destructuring and lib function usage are appropriate.

---

30-42: Proper Stripe API integration.

The HTTP request implementation is correct with proper authentication, endpoint URL, and parameter handling. The default limit of 100 is reasonable for search operations.

---

44-50: Correct output handling implementation.

The lib.sendArrayOutput usage is proper with appropriate parameters. The records parameter correctly references the nested data structure from Stripe's API response.

Reviewing files that changed from the base of the PR and between be5900d and b31091d.

• src/appmixer/stripe/core/CreateCustomer/component.json (1 hunks)
• src/appmixer/stripe/core/CreateInvoice/CreateInvoice.js (1 hunks)
• src/appmixer/stripe/core/CreateInvoice/component.json (1 hunks)
• src/appmixer/stripe/core/FindCharges/FindCharges.js (1 hunks)
• src/appmixer/stripe/core/FindCharges/component.json (1 hunks)
• src/appmixer/stripe/core/FindCustomers/FindCustomers.js (1 hunks)
• src/appmixer/stripe/core/FindCustomers/component.json (1 hunks)
• src/appmixer/stripe/core/FindInvoices/FindInvoices.js (1 hunks)
• src/appmixer/stripe/core/FindInvoices/component.json (1 hunks)
• src/appmixer/stripe/core/FindPaymentIntent/FindPaymentIntent.js (1 hunks)
• src/appmixer/stripe/core/FindPaymentIntent/component.json (1 hunks)
• src/appmixer/stripe/core/FindPaymentMethods/FindPaymentMethods.js (1 hunks)
• src/appmixer/stripe/core/FindPaymentMethods/component.json (1 hunks)
• src/appmixer/stripe/core/FindRefunds/FindRefunds.js (1 hunks)
• src/appmixer/stripe/core/FindRefunds/component.json (1 hunks)
• src/appmixer/stripe/core/UpdateCustomer/component.json (1 hunks)

• src/appmixer/stripe/core/UpdateCustomer/component.json

• src/appmixer/stripe/core/FindCustomers/component.json
• src/appmixer/stripe/core/FindInvoices/component.json
• src/appmixer/stripe/core/FindRefunds/component.json
• src/appmixer/stripe/core/FindCharges/component.json
• src/appmixer/stripe/core/FindPaymentIntent/component.json
• src/appmixer/stripe/core/CreateCustomer/component.json
• src/appmixer/stripe/core/CreateInvoice/component.json

src/appmixer/stripe/core/FindPaymentIntent/FindPaymentIntent.js (4)

3-3: LGTM!

The import statement correctly references the shared library for Stripe integration utilities.

---

5-17: LGTM!

The schema definition accurately reflects the Stripe Payment Intent object structure with appropriate types and titles. The nullable fields (customer, description) are correctly defined with union types.

---

19-28: LGTM!

The module export structure and generateOutputPortOptions handling follows the standard Appmixer pattern correctly. The function definition properly has an empty line after it as required by the coding guidelines.

---

70-76: LGTM!

The output formatting using the shared library function is implemented correctly with proper parameters for array output handling.

src/appmixer/stripe/core/FindCustomers/FindCustomers.js (5)

5-33: Well-structured schema definition for Stripe customer objects.

The schema comprehensively covers all relevant Stripe customer fields including nested address properties with appropriate type definitions and nullable fields.

---

39-44: Proper handling of output port options generation.

The implementation correctly uses the shared library function with appropriate parameters for generating output port options.

---

47-76: Effective implementation of conditional API endpoint selection.

The logic correctly uses different Stripe endpoints based on query presence - search endpoint for queries and list endpoint for general listing. Both requests include proper authentication and consistent limit parameters.

---

82-84: Appropriate handling of empty results.

The implementation correctly sends empty results to the notFound port, which aligns with the component's design pattern.

---

86-92: Proper output handling using shared library function.

The code correctly uses lib.sendArrayOutput with appropriate parameters for handling array output and output type formatting.

src/appmixer/stripe/core/FindInvoices/FindInvoices.js (6)

5-26: Well-structured schema definition.

The schema comprehensively covers the key invoice fields from Stripe's API, including proper type definitions for nullable fields like customer_email and customer_name.

---

32-37: Proper handling of output port options.

The implementation correctly uses the library function to generate output port options when requested, following the established Appmixer pattern.

---

43-54: Correct implementation of Stripe invoice search.

The search endpoint usage aligns with Stripe's API documentation, with proper authorization and reasonable default limit.

---

58-69: Correct implementation of Stripe invoice listing.

The list endpoint usage follows Stripe's API patterns consistently with the search implementation.

---

75-77: Proper handling of empty results.

The implementation correctly routes empty results to the notFound output port, following the established pattern for "Find" components.

---

79-84: Correct usage of library output formatting.

The sendArrayOutput function call properly handles different output types and follows the established pattern for array-based results.

src/appmixer/stripe/core/FindCharges/FindCharges.js (3)

5-12: Schema definition looks good.

The schema correctly defines the structure for Stripe charge objects with proper field types and titles.

---

23-27: Parameter construction follows Stripe API correctly.

The parameter building logic properly handles optional customer and payment intent filters, with a reasonable default limit.

---

39-44: Error handling and output processing implemented correctly.

The component properly handles empty results by sending to the 'notFound' port and uses the standard library function for array output formatting.

src/appmixer/stripe/core/CreateInvoice/CreateInvoice.js (5)

1-1: Static analysis suggests removing 'use strict' but coding guidelines require it.

The static analysis tool flags the 'use strict'; directive as redundant in ES modules. However, the coding guidelines specifically state that this directive is "desirable" for src/appmixer/**/*.js files. Following the established coding guidelines is appropriate here.

---

3-12: LGTM: Function structure follows Appmixer connector pattern.

The module exports and async receive function structure correctly follows the expected pattern for Appmixer connectors. The parameter destructuring from context.messages.in.content is clean and appropriate.

---

21-28: LGTM: Conditional field logic addresses Stripe API requirements.

The conditional logic correctly handles the Stripe API requirement that when collection_method is 'send_invoice', either due_date or days_until_due must be specified. The Unix timestamp conversion for due_date is properly implemented.

---

30-38: LGTM: HTTP request configuration is correct.

The HTTP request to Stripe's API is properly configured with the correct method, URL, headers, and data format. The authorization header correctly uses the context's API key.

---

40-41: LGTM: Response handling follows expected pattern.

The response is correctly sent through the context's output channel using sendJson.

src/appmixer/stripe/core/FindRefunds/FindRefunds.js (3)

8-14: LGTM: Input handling and output port options.

The input parameter destructuring and conditional output port options generation follow the established pattern correctly.

---

16-21: LGTM: Parameter construction logic.

The parameter construction correctly handles optional charge and paymentIntent filters and sets a reasonable default limit.

---

32-38: LGTM: Response handling and output formatting.

The response handling correctly checks for empty results and uses the library function for array output formatting.