try:
    can_ignore_error = data['error']['code'] in ignore_error_codes
excep...</summary>

> `**/*.py`: Use try/except for concise error handling when accessing nested dictionary keys:
> 
> ```python
> try:
>     can_ignore_error = data['error']['code'] in ignore_error_codes
> except KeyError:
>     can_ignore_error = False
> ```
> 
> ❌ Avoid Verbose Chained Conditionals:
> ```python
> can_ignore_error = (
>     'code' in data['error']
>     and data['error']['code'] in ignore_error_codes
> )
> ```
> 
> Explanation:
> The try/except approach:
> 
> Reduces code complexity and nesting
> Improves readability by focusing on the "happy path" logic
> Follows Python's "easier to ask forgiveness than permission" (EAFP) idiom
> 
> Severity: Important (Not a Nitpick)
> This pattern significantly improves code maintainability and readability, especially as dictionary access patterns become more complex.

- `facturapi/resources/invoices.py`

</details>
<details>
<summary>`**/*.py`: Context
Agave is our internal Python library for processing SQS messages. The @task decorator can automatically convert JSON to Pydantic models.

Rule
Always annotate @t...</summary>

> `**/*.py`: Context
> Agave is our internal Python library for processing SQS messages. The @task decorator can automatically convert JSON to Pydantic models.
> 
> Rule
> Always annotate @task parameters with Pydantic models instead of manually converting dictionaries.
> 
> Correct Pattern
> ```python
> from pydantic import BaseModel
> from agave.tasks.sqs_tasks import task
> 
> class User(BaseModel):
>     name: str
>     age: int
>     
> @task(queue_url=QUEUE_URL, region_name='us-east-1')
> async def task_validator(message: User) -> None:
>     # The message is already a User instance - no conversion needed
>     print(message.name)  # Direct attribute access
> ```
> 
> Incorrect Pattern
> ```python
> from pydantic import BaseModel
> from agave.tasks.sqs_tasks import task
> 
> class User(BaseModel):
>     name: str
>     age: int
>     
> @task(queue_url=QUEUE_URL, region_name='us-east-1')
> async def task_validator(message_data: dict) -> None:  # or unannotated parameter
>     # Unnecessary conversion
>     message = User(**message_data)
>     print(message.name)
> ```
> 
> Explanation
> The Agave @task decorator automatically:
> 
> - Reads JSON messages from SQS queues
> - Converts them to Pydantic model instances when the handler parameter is annotated
> - Performs validation based on the Pydantic model

- `facturapi/resources/invoices.py`

</details>

</details><details>
<summary>🧬 Code Definitions (1)</summary>

<details>
<summary>facturapi/resources/invoices.py (1)</summary><blockquote>

<details>
<summary>facturapi/http/client.py (2)</summary>

* `post` (67-69)
* `get` (59-65)

</details>

</blockquote></details>

</details><details>
<summary>🪛 Ruff (0.8.2)</summary>

<details>
<summary>facturapi/resources/invoices.py</summary>

223-224: Use a single `if` statement instead of nested `if` statements

Combine `if` statements using `and`

(SIM102)

---

224-224: Multiple `isinstance` calls for `data`, merge into a single call

Merge `isinstance` calls for `data`

(SIM101)

</details>

</details>

</details>

<details>
<summary>🔇 Additional comments (2)</summary><blockquote>

<details>
<summary>tests/resources/cassettes/test_send_invoice_by_email_false.yaml (1)</summary>

`1-70`: **LGTM! Test cassette looks well-structured**

The test cassette properly mocks the API response for a failed email send operation, returning `{"ok":false}`. This will be useful for testing error handling in the client code.

</details>
<details>
<summary>tests/resources/cassettes/test_send_invoice_by_email_without_email.yaml (1)</summary>

`1-70`: **LGTM! Success case test cassette is well-structured**

The test cassette properly mocks a successful API response for sending an invoice email when no specific email address is provided. This tests the default behavior of sending to the customer's registered email.

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->

try:
    can_ignore_error = data['error']['code'] in ignore_error_codes
excep...</summary>

> `**/*.py`: Use try/except for concise error handling when accessing nested dictionary keys:
> 
> ```python
> try:
>     can_ignore_error = data['error']['code'] in ignore_error_codes
> except KeyError:
>     can_ignore_error = False
> ```
> 
> ❌ Avoid Verbose Chained Conditionals:
> ```python
> can_ignore_error = (
>     'code' in data['error']
>     and data['error']['code'] in ignore_error_codes
> )
> ```
> 
> Explanation:
> The try/except approach:
> 
> Reduces code complexity and nesting
> Improves readability by focusing on the "happy path" logic
> Follows Python's "easier to ask forgiveness than permission" (EAFP) idiom
> 
> Severity: Important (Not a Nitpick)
> This pattern significantly improves code maintainability and readability, especially as dictionary access patterns become more complex.

- `facturapi/resources/invoices.py`

</details>
<details>
<summary>`**/*.py`: Context
Agave is our internal Python library for processing SQS messages. The @task decorator can automatically convert JSON to Pydantic models.

Rule
Always annotate @t...</summary>

> `**/*.py`: Context
> Agave is our internal Python library for processing SQS messages. The @task decorator can automatically convert JSON to Pydantic models.
> 
> Rule
> Always annotate @task parameters with Pydantic models instead of manually converting dictionaries.
> 
> Correct Pattern
> ```python
> from pydantic import BaseModel
> from agave.tasks.sqs_tasks import task
> 
> class User(BaseModel):
>     name: str
>     age: int
>     
> @task(queue_url=QUEUE_URL, region_name='us-east-1')
> async def task_validator(message: User) -> None:
>     # The message is already a User instance - no conversion needed
>     print(message.name)  # Direct attribute access
> ```
> 
> Incorrect Pattern
> ```python
> from pydantic import BaseModel
> from agave.tasks.sqs_tasks import task
> 
> class User(BaseModel):
>     name: str
>     age: int
>     
> @task(queue_url=QUEUE_URL, region_name='us-east-1')
> async def task_validator(message_data: dict) -> None:  # or unannotated parameter
>     # Unnecessary conversion
>     message = User(**message_data)
>     print(message.name)
> ```
> 
> Explanation
> The Agave @task decorator automatically:
> 
> - Reads JSON messages from SQS queues
> - Converts them to Pydantic model instances when the handler parameter is annotated
> - Performs validation based on the Pydantic model

- `facturapi/resources/invoices.py`

</details>

</details><details>
<summary>🧬 Code Definitions (1)</summary>

<details>
<summary>facturapi/resources/invoices.py (1)</summary><blockquote>

<details>
<summary>facturapi/http/client.py (2)</summary>

* `post` (67-69)
* `get` (59-65)

</details>

</blockquote></details>

</details>

</details>

<details>
<summary>🔇 Additional comments (1)</summary><blockquote>

<details>
<summary>facturapi/resources/invoices.py (1)</summary>

`195-226`: **Well-implemented email sending functionality**

The implementation of the `send_by_email` method looks good. It follows the previous review suggestions by accepting email addresses directly rather than through a request model, and correctly returns a boolean value. The method properly handles different input types (string or list) and includes appropriate error handling.

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->

try:
    can_ignore_error = data['error']['code'] in ignore_error_codes
excep...</summary>

> `**/*.py`: Use try/except for concise error handling when accessing nested dictionary keys:
> 
> ```python
> try:
>     can_ignore_error = data['error']['code'] in ignore_error_codes
> except KeyError:
>     can_ignore_error = False
> ```
> 
> ❌ Avoid Verbose Chained Conditionals:
> ```python
> can_ignore_error = (
>     'code' in data['error']
>     and data['error']['code'] in ignore_error_codes
> )
> ```
> 
> Explanation:
> The try/except approach:
> 
> Reduces code complexity and nesting
> Improves readability by focusing on the "happy path" logic
> Follows Python's "easier to ask forgiveness than permission" (EAFP) idiom
> 
> Severity: Important (Not a Nitpick)
> This pattern significantly improves code maintainability and readability, especially as dictionary access patterns become more complex.

- `facturapi/resources/invoices.py`

</details>
<details>
<summary>`**/*.py`: Context
Agave is our internal Python library for processing SQS messages. The @task decorator can automatically convert JSON to Pydantic models.

Rule
Always annotate @t...</summary>

> `**/*.py`: Context
> Agave is our internal Python library for processing SQS messages. The @task decorator can automatically convert JSON to Pydantic models.
> 
> Rule
> Always annotate @task parameters with Pydantic models instead of manually converting dictionaries.
> 
> Correct Pattern
> ```python
> from pydantic import BaseModel
> from agave.tasks.sqs_tasks import task
> 
> class User(BaseModel):
>     name: str
>     age: int
>     
> @task(queue_url=QUEUE_URL, region_name='us-east-1')
> async def task_validator(message: User) -> None:
>     # The message is already a User instance - no conversion needed
>     print(message.name)  # Direct attribute access
> ```
> 
> Incorrect Pattern
> ```python
> from pydantic import BaseModel
> from agave.tasks.sqs_tasks import task
> 
> class User(BaseModel):
>     name: str
>     age: int
>     
> @task(queue_url=QUEUE_URL, region_name='us-east-1')
> async def task_validator(message_data: dict) -> None:  # or unannotated parameter
>     # Unnecessary conversion
>     message = User(**message_data)
>     print(message.name)
> ```
> 
> Explanation
> The Agave @task decorator automatically:
> 
> - Reads JSON messages from SQS queues
> - Converts them to Pydantic model instances when the handler parameter is annotated
> - Performs validation based on the Pydantic model

- `facturapi/resources/invoices.py`

</details>

</details><details>
<summary>🧬 Code Definitions (1)</summary>

<details>
<summary>facturapi/resources/invoices.py (1)</summary><blockquote>

<details>
<summary>facturapi/http/client.py (2)</summary>

* `post` (67-69)
* `get` (59-65)

</details>

</blockquote></details>

</details>

</details>

<details>
<summary>🔇 Additional comments (2)</summary><blockquote>

<details>
<summary>facturapi/resources/invoices.py (2)</summary>

`14-14`: **Great use of relative imports for internal modules.**

This change follows our coding guidelines by using relative imports for internal modules.

---

`195-225`: **Well-implemented feature that follows previous feedback.**

The implementation effectively addresses all previous review comments:
1. Uses proper type annotation with `Optional[Union[str, List[str]]] = None`
2. Accepts email strings directly for a simpler interface
3. Returns a boolean value as suggested

The method has comprehensive documentation and handles both the case of using the customer's default email and specifying custom email addresses.

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->

try:
    can_ignore_error = data['error']['code'] in ignore_error_codes
excep...</summary>

> `**/*.py`: Use try/except for concise error handling when accessing nested dictionary keys:
> 
> ```python
> try:
>     can_ignore_error = data['error']['code'] in ignore_error_codes
> except KeyError:
>     can_ignore_error = False
> ```
> 
> ❌ Avoid Verbose Chained Conditionals:
> ```python
> can_ignore_error = (
>     'code' in data['error']
>     and data['error']['code'] in ignore_error_codes
> )
> ```
> 
> Explanation:
> The try/except approach:
> 
> Reduces code complexity and nesting
> Improves readability by focusing on the "happy path" logic
> Follows Python's "easier to ask forgiveness than permission" (EAFP) idiom
> 
> Severity: Important (Not a Nitpick)
> This pattern significantly improves code maintainability and readability, especially as dictionary access patterns become more complex.

- `facturapi/resources/invoices.py`
- `tests/resources/test_invoices.py`

</details>
<details>
<summary>`**/*.py`: Context
Agave is our internal Python library for processing SQS messages. The @task decorator can automatically convert JSON to Pydantic models.

Rule
Always annotate @t...</summary>

> `**/*.py`: Context
> Agave is our internal Python library for processing SQS messages. The @task decorator can automatically convert JSON to Pydantic models.
> 
> Rule
> Always annotate @task parameters with Pydantic models instead of manually converting dictionaries.
> 
> Correct Pattern
> ```python
> from pydantic import BaseModel
> from agave.tasks.sqs_tasks import task
> 
> class User(BaseModel):
>     name: str
>     age: int
>     
> @task(queue_url=QUEUE_URL, region_name='us-east-1')
> async def task_validator(message: User) -> None:
>     # The message is already a User instance - no conversion needed
>     print(message.name)  # Direct attribute access
> ```
> 
> Incorrect Pattern
> ```python
> from pydantic import BaseModel
> from agave.tasks.sqs_tasks import task
> 
> class User(BaseModel):
>     name: str
>     age: int
>     
> @task(queue_url=QUEUE_URL, region_name='us-east-1')
> async def task_validator(message_data: dict) -> None:  # or unannotated parameter
>     # Unnecessary conversion
>     message = User(**message_data)
>     print(message.name)
> ```
> 
> Explanation
> The Agave @task decorator automatically:
> 
> - Reads JSON messages from SQS queues
> - Converts them to Pydantic model instances when the handler parameter is annotated
> - Performs validation based on the Pydantic model

- `facturapi/resources/invoices.py`
- `tests/resources/test_invoices.py`

</details>
<details>
<summary>`**/*.py`: ## MANDATORY: Use built-in Pydantic validators

### Description
Avoid creating custom validators that duplicate functionality already provided by Pydantic's built-in val...</summary>

> `**/*.py`: ## MANDATORY: Use built-in Pydantic validators
> 
> ### Description
> Avoid creating custom validators that duplicate functionality already provided by Pydantic's built-in validators, pydantic_extra_types package, or third-party Pydantic validator libraries. This improves code maintainability and reduces unnecessary unit tests.
> 
> ### Bad Practice
> ```python
> from pydantic import BaseModel, field_validator
> 
> class MyValidator(BaseModel):
>     location: str
>     
>     @field_validator('location')
>     def validate_location(cls, value: str) -> str:
>         values = value.split(',')
>         if len(values) != 3:
>             raise ValueError('Must provide exactly 3 values for location')
>         # Custom validation logic that duplicates functionality
>         return value
> ```
> 
> ### Good Practice
> ```python
> from pydantic import BaseModel
> from pydantic_extra_types.coordinate import Coordinate
> 
> class MyValidator(BaseModel):
>     location: Coordinate
> ```
> 
> ### Unit Test Guidelines
> Do not write unit tests specifically for validating the behavior of Pydantic's built-in validators. These are already well-tested by the Pydantic library itself.
> 
> #### Tests to Remove
> ```python
> def test_invalid_location():
>     pytest.raises(ValidationError):
>         MyValidator(location='foo,bar')
> ```
> 
> ### Rule Enforcement
> This is a mandatory rule, not a refactoring suggestion. Changes must be implemented when:
> 1. A custom validator replicates functionality already available in Pydantic's ecosystem
> 2. There is a suitable built-in, pydantic_extra_types, or third-party Pydantic validator available
> 
> Actions required:
> 1. Replace custom validators with appropriate existing validators
> 2. Remove unnecessary unit tests that only validate built-in Pydantic validation behavior
> 3. Block PRs that introduce new custom validators when alternatives exist

- `facturapi/resources/invoices.py`
- `tests/resources/test_invoices.py`

</details>

</details><details>
<summary>🧬 Code Definitions (1)</summary>

<details>
<summary>facturapi/resources/invoices.py (1)</summary><blockquote>

<details>
<summary>facturapi/http/client.py (2)</summary>

* `post` (67-69)
* `get` (59-65)

</details>

</blockquote></details>

</details>

</details>

<details>
<summary>🔇 Additional comments (6)</summary><blockquote>

<details>
<summary>tests/resources/cassettes/test_send_invoice_by_email_invoice_not_found.yaml (1)</summary>

`1-77`: **LGTM: Well-structured test cassette for error handling**

The VCR cassette is correctly structured to test the invoice-not-found scenario. It properly simulates the API's 400 response with an appropriate error message when an invalid invoice ID is provided.

</details>
<details>
<summary>facturapi/resources/invoices.py (1)</summary>

`14-14`: **Correct usage of relative import**

Good job using relative import for internal modules, which aligns with the project's coding guidelines.

</details>
<details>
<summary>tests/resources/test_invoices.py (4)</summary>

`7-11`: **LGTM: Appropriate import of exception classes**

The proper exception classes are imported for the error handling test case.

---

`111-116`: **LGTM: Test for sending without email parameter**

Good test case covering the scenario where no email recipients are specified, which will use the customer's registered email.

---

`118-127`: **LGTM: Test for sending with email parameter**

Good test case for the scenario where specific email recipients are provided.

---

`136-143`: **LGTM: Test for invoice not found scenario**

Good test case covering error handling when an invoice ID doesn't exist. It properly verifies that the exception is raised and contains the expected error message.

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->

try:
    can_ignore_error = data['error']['code'] in ignore_error_codes
excep...</summary>

> `**/*.py`: Use try/except for concise error handling when accessing nested dictionary keys:
> 
> ```python
> try:
>     can_ignore_error = data['error']['code'] in ignore_error_codes
> except KeyError:
>     can_ignore_error = False
> ```
> 
> ❌ Avoid Verbose Chained Conditionals:
> ```python
> can_ignore_error = (
>     'code' in data['error']
>     and data['error']['code'] in ignore_error_codes
> )
> ```
> 
> Explanation:
> The try/except approach:
> 
> Reduces code complexity and nesting
> Improves readability by focusing on the "happy path" logic
> Follows Python's "easier to ask forgiveness than permission" (EAFP) idiom
> 
> Severity: Important (Not a Nitpick)
> This pattern significantly improves code maintainability and readability, especially as dictionary access patterns become more complex.

- `facturapi/resources/invoices.py`

</details>
<details>
<summary>`**/*.py`: Context
Agave is our internal Python library for processing SQS messages. The @task decorator can automatically convert JSON to Pydantic models.

Rule
Always annotate @t...</summary>

> `**/*.py`: Context
> Agave is our internal Python library for processing SQS messages. The @task decorator can automatically convert JSON to Pydantic models.
> 
> Rule
> Always annotate @task parameters with Pydantic models instead of manually converting dictionaries.
> 
> Correct Pattern
> ```python
> from pydantic import BaseModel
> from agave.tasks.sqs_tasks import task
> 
> class User(BaseModel):
>     name: str
>     age: int
>     
> @task(queue_url=QUEUE_URL, region_name='us-east-1')
> async def task_validator(message: User) -> None:
>     # The message is already a User instance - no conversion needed
>     print(message.name)  # Direct attribute access
> ```
> 
> Incorrect Pattern
> ```python
> from pydantic import BaseModel
> from agave.tasks.sqs_tasks import task
> 
> class User(BaseModel):
>     name: str
>     age: int
>     
> @task(queue_url=QUEUE_URL, region_name='us-east-1')
> async def task_validator(message_data: dict) -> None:  # or unannotated parameter
>     # Unnecessary conversion
>     message = User(**message_data)
>     print(message.name)
> ```
> 
> Explanation
> The Agave @task decorator automatically:
> 
> - Reads JSON messages from SQS queues
> - Converts them to Pydantic model instances when the handler parameter is annotated
> - Performs validation based on the Pydantic model

- `facturapi/resources/invoices.py`

</details>
<details>
<summary>`**/*.py`: ## MANDATORY: Use built-in Pydantic validators

### Description
Avoid creating custom validators that duplicate functionality already provided by Pydantic's built-in val...</summary>

> `**/*.py`: ## MANDATORY: Use built-in Pydantic validators
> 
> ### Description
> Avoid creating custom validators that duplicate functionality already provided by Pydantic's built-in validators, pydantic_extra_types package, or third-party Pydantic validator libraries. This improves code maintainability and reduces unnecessary unit tests.
> 
> ### Bad Practice
> ```python
> from pydantic import BaseModel, field_validator
> 
> class MyValidator(BaseModel):
>     location: str
>     
>     @field_validator('location')
>     def validate_location(cls, value: str) -> str:
>         values = value.split(',')
>         if len(values) != 3:
>             raise ValueError('Must provide exactly 3 values for location')
>         # Custom validation logic that duplicates functionality
>         return value
> ```
> 
> ### Good Practice
> ```python
> from pydantic import BaseModel
> from pydantic_extra_types.coordinate import Coordinate
> 
> class MyValidator(BaseModel):
>     location: Coordinate
> ```
> 
> ### Unit Test Guidelines
> Do not write unit tests specifically for validating the behavior of Pydantic's built-in validators. These are already well-tested by the Pydantic library itself.
> 
> #### Tests to Remove
> ```python
> def test_invalid_location():
>     pytest.raises(ValidationError):
>         MyValidator(location='foo,bar')
> ```
> 
> ### Rule Enforcement
> This is a mandatory rule, not a refactoring suggestion. Changes must be implemented when:
> 1. A custom validator replicates functionality already available in Pydantic's ecosystem
> 2. There is a suitable built-in, pydantic_extra_types, or third-party Pydantic validator available
> 
> Actions required:
> 1. Replace custom validators with appropriate existing validators
> 2. Remove unnecessary unit tests that only validate built-in Pydantic validation behavior
> 3. Block PRs that introduce new custom validators when alternatives exist

- `facturapi/resources/invoices.py`

</details>

</details><details>
<summary>🧬 Code Definitions (1)</summary>

<details>
<summary>facturapi/resources/invoices.py (1)</summary><blockquote>

<details>
<summary>facturapi/http/client.py (2)</summary>

* `post` (67-69)
* `get` (59-65)

</details>

</blockquote></details>

</details>

</details>

<details>
<summary>🔇 Additional comments (2)</summary><blockquote>

<details>
<summary>facturapi/resources/invoices.py (2)</summary>

`14-14`: **LGTM! Correct use of relative imports**

The change to use relative imports for internal modules follows the coding guidelines correctly.

---

`220-225`: **LGTM! Clean and concise implementation**

The implementation is clean and follows the direct approach suggested in previous reviews. It handles both single email addresses and lists of addresses, and returns a boolean value as recommended.

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->