ResendEmail Endpoint

1. General Description

Endpoint

POST /ordersv2/{id}/email/send

Purpose

This endpoint is used to manually trigger sending or re-sending an email related to an existing order. It is intended for operational or support use cases where a business email must be sent again for an order that has already gone through part of its lifecycle.

The endpoint does not return a mail-specific response object. It returns the updated order resource and starts an asynchronous email dispatch process.

Typical use cases

• Re-send an order confirmation email
• Re-send a prebilling email
• Re-send a cancellation email
• Re-send a partial refund email
• Trigger offline payment reminder / non-recurring subscription communication when the order state allows it

Response behavior

• On accepted processing, the endpoint returns 202 Accepted
• The response body is the order object
• Email sending itself is asynchronous
• The returned order can already contain a newly created email record, but the final external emailId may be filled later

2. Path Parameters

Name	Description	R/O
id	Unique identifier of the order for which the email must be sent.	R

3. Query Parameters

Name	Description	R/O
reason	Business or audit reason attached to the request. If not provided, a default internal reason is used.	O

4. Body Input Parameters

Name	Description	R/O
template	Logical email type to send. This is the main driver of validation and processing.	R
to	Recipient email override. If omitted, the order end-user email is used.	O
paymentId	Payment identifier attached to the generated email metadata when relevant.	O

Supported template values

• PREBILLING
• ORDERCONFIRMATION
• CANCELLATION
• PARTIAL_REFUND
• OFFLINE_PAYMENT_PENDING
• NON_RECURRING_PREBILLING
• NON_RECURRING_PAYMENT_ATTEMPT
• NON_RECURRING_PAYMENT_SUBSCRIPTION_EXPIRED

5. Logic of Processing

Use Case

Use case name

Re-send an email for an existing order

Primary actor

Internal support or operational caller

Preconditions

• The order exists
• The caller is authorized to use the endpoint
• The requested template is supported by this endpoint
• The order is in a state that allows the selected email to be sent

Main Scenario

1. The caller sends the request with the order id, the email template, and optional parameters such as recipient override and reason.
2. The system loads the target order.
3. The system records that an email-send request was made for audit and traceability.
4. The system validates whether the requested template is allowed for this endpoint.
5. The system validates whether the current order state allows the selected email to be sent.
6. When needed, the system derives additional internal data from the order context instead of trusting the request body. Examples include cancellation reason or payment-related context.
7. The system resolves the concrete email-builder template to use. This resolution depends on the requested logical template and on the order context, such as order source, layout, subscription context, trial/conversion context, and similar business attributes.
8. The system determines the recipient:
   • if to is provided, that value is used
   • otherwise, the order end-user email is used
9. The system creates a new email entry on the order and marks the related email workflow as pending.
10. The system sends an asynchronous request to the email service.
11. The endpoint returns 202 Accepted with the updated order resource.
12. Later, when the email service answers asynchronously:

• on success, the corresponding email workflow is marked as completed and the external emailId is attached
• on failure, the corresponding email workflow is marked as failed

Alternatives

A1. Order does not exist

1. The caller sends a request with an unknown order id.
2. The system cannot find the order.
3. The request is rejected with a not-found response.

Result

• No email is sent
• No order is returned

A2. Unsupported template value

1. The caller sends a template that exists in the shared request model but is not supported by this endpoint.
2. The system rejects the request during validation.

Result

• The request fails with a bad-request response
• No email is sent

A3. The order state is not eligible for the selected template

1. The caller sends a supported template.
2. The system checks the order status rules for that template.
3. The order does not satisfy the business conditions.

Typical examples

• PREBILLING: rejected if payment is already completed or prebilling is not applicable
• ORDERCONFIRMATION: rejected if payment is not completed, cancellation has already been triggered, or the confirmation email is not in a resendable state
• CANCELLATION: rejected if cancellation email processing has not progressed enough to justify a resend
• PARTIAL_REFUND: rejected if partial refund email processing has not progressed enough to justify a resend
• OFFLINE_PAYMENT_PENDING: rejected if payment status is not pending

Result

• The request fails with a bad-request response
• No email is sent

A4. Store configuration disables alternative non-recurring communications

1. The caller requests NON_RECURRING_PAYMENT_ATTEMPT or NON_RECURRING_PAYMENT_SUBSCRIPTION_EXPIRED.
2. The store configuration indicates that this type of alternative communication is disabled.

Result

• The endpoint returns the order as-is
• No email is sent
• No new resend action is executed

A5. Prebilling resume-offer case no longer requires an email

1. The caller requests a prebilling email for a resume-offer scenario.
2. During business resolution, the system determines that the subscription timing no longer requires sending the email.

Result

• No email is sent
• The prebilling workflow is internally moved forward instead
• The returned order reflects that internal update

A6. Synchronous failure while dispatching the email request

1. The order passed validation and a pending email record was created.
2. The system attempts to call the asynchronous email service.
3. The dispatch fails immediately.

Result

• The email workflow is marked as failed
• The request ends with an error response

A7. Asynchronous failure after the endpoint already returned

1. The endpoint accepted the request and returned the order with a pending email workflow.
2. Later, the email service returns a failure.

Result

• The order email workflow is updated to failed
• The initial HTTP response is not changed retroactively

6. Output Parameters

The endpoint returns the full order resource. The table below lists only the response fields that are directly relevant to this resend-email operation.

Name	Description	R/O
id	Order identifier.	R
prebillingStatus	Prebilling email workflow status when the resend concerns a prebilling-related email.	O
emailConfirmationStatus	Order confirmation email workflow status when the resend concerns order confirmation.	O
emailCancellationStatus	Cancellation email workflow status when the resend concerns cancellation.	O
partialRefundEmailStatus	Partial refund email workflow status when the resend concerns partial refund.	O
emails	Collection of email records attached to the order.	O
emails[].emailId	External identifier returned by the email service. It can be absent in the immediate response and filled later after asynchronous completion.	O
emails[].templateName	Logical template name used for the email entry.	O
emails[].templateDefinitionName	Concrete template definition used by the downstream email builder.	O
emails[].recipient	Final recipient email address used for the send operation.	O
emails[].paymentId	Payment identifier attached to the email record when relevant.	O
emails[].createDate	Timestamp of email record creation.	O

7. Notes

• The response is an order resource, not a dedicated resend-email response object
• Email sending is asynchronous, so the immediate response should be treated as accepted processing, not final delivery confirmation
• A newly added email entry can appear in the response before the external emailId is available