Skip to content
Developers/Documentation
View Markdown

Loading documentation…

Order management

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

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

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

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

  • 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

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 for those flows.

See Files for invoice/ticket PDFs and Exports 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.