---
description: "Edit billing data, confirm or drop reservations, resend messages, mark invoices paid, and cancel eligible orders."
group: "Resources"
order: 19
---

# Order management

Use the order's current lifecycle capabilities for organizer actions.

## Read current capabilities {#read-current-capabilities}

`GET /{event_id}/orders/detail_data/{order_id}.json` returns `{ok,data}` with organizer context, payment capabilities, pending actions and mail-delivery information. Ordinary order responses also expose `payment_state`. Read them immediately before a dependent write. Provider payment, invoice settlement, reservation, refund and cancellation remain distinct facts.

## Edit an order {#edit-an-order}

PUT `/{event_id}/orders/edit/{order_id}.json` with allowed `Order` billing/contact fields and registration answers. The `can_edit` gate and field validation apply.

```
{"Order":{"firstname":"Alex","lastname":"Example","email":"alex@example.com"}}
```

A successful edit can return `{"ok":true}` or a `new_order_created` UUID for a replacement version. Follow the returned ID and refresh related records. Older order revisions, invalid promo codes and validation errors can return legacy JSON errors with HTTP 200. This endpoint does not offer arbitrary payment-state editing.

## Manage reservations {#manage-reservations}

| Method and action after `/{event_id}/orders/` | Effect |
| --- | --- |
| `PUT confirm_reservation/{order_id}.json` | Finalize an eligible reservation; queues customer email by default. |
| `PUT resend_reservation/{order_id}.json` | Queue the reservation email again. |
| `POST drop_reservation/{order_id}.json` | Drop an eligible reservation through the lifecycle service. |

To confirm without queuing mail, include `{"Order":{"dont_email":1}}`. The implementation tests whether that key is present: even `dont_email:0` suppresses mail. Omit it to send. Require `ok:true`; reread the order after completion.

## Invoice and cancellation actions {#invoice-and-cancellation-actions}

-   PUT `/{event_id}/orders/resend/{order_id}.json` queues an eligible invoice/order email; company clearance can also apply.
-   PUT `/{event_id}/orders/pay/{order_id}.json` marks an eligible invoice paid through `can_mark_invoice_paid`. It does not force online provider-payment success.
-   PUT `/{event_id}/orders/cancel/{order_id}.json` cancels an eligible order through `can_cancel`; it can create a credit invoice and notifications.

Failures may return `{error: ...}` with HTTP 200. An online provider payment can return `provider_refund_required`. Never treat an order cancellation request as confirmation that money has been refunded.

## Refund and checkout workflows {#refund-and-checkout-workflows}

Provider refunds use the organizer's `cancel_refund` and `refund_attendees` workflow, with selections, confirmation, operation state and provider calls. Telesales and duplicate-and-edit checkout also maintain browser/session state. These workflows are not published here as a single stateless JSON refund or order-creation endpoint. Use the organizer UI and [ticket shop](/en-us/docs/embed-ticket-shop.md) for those flows.

See [Files](/en-us/docs/files-and-exports.md) for invoice/ticket PDFs and [Exports](/en-us/docs/exports.md) for order CSV/Excel downloads. Successful financial and mail-producing actions were source-reviewed; test them with your approved synthetic/payment environment before enabling them.