Writing data

Create and manage event data with the existing organizer HTTP resources.

Use the methods and paths in the OpenAPI reference. The reference publishes PUT when supported, and POST for actions that require it. These action URLs retain CakePHP model envelopes and existing lifecycle rules. They are not generic REST updates or JSON Patch endpoints.

Authenticate and authorize

Send HTTP Basic over HTTPS from your server, using an active organizer account on your configured organization origin. Basic requests use the organizer's company and event permissions. Browser sessions retain their CSRF requirements. Event UUIDs and nested product, category, attendee and promo IDs must be authorized for the requested event.

File management requires company administrator rights. Event opening can require company clearance. Orders and attendees also enforce payment-state capabilities. Review permissions before choosing an integration account.

Send JSON envelopes

Send Accept: application/json and Content-Type: application/json. Use the action's envelope, such as Product, OrderLine, Waitinglist or Comment. Uploads instead use multipart form data. Set PAYDRO_ORIGIN to your organizer origin; dedicated developer hosts serve documentation.

curl --fail-with-body --user "$PAYDRO_EMAIL:$PAYDRO_PASSWORD" \
  --request PUT \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '{"Product":{"title":"General admission","price":"0.00","stock":100,"visible":1}}' \
  "$PAYDRO_ORIGIN/$EVENT_ID/products/add/free.json"

Use an event's existing category or explicitly submit category_id/category_new. Read product management before executing this example. Examples in the reference use synthetic IDs: replace them with IDs from your authorized event.

Recognize success

HTTP 200 alone does not prove success. Product validation can return submitted form data or [data, error]. Order actions can return {error: ...} with 200. Validate HTTP status, content type and the documented body. Disable automatic redirect following so login or organizer HTML does not appear to be successful JSON. Read error handling for the authentication and legacy error formats.

Read before retrying

The API does not publish a general idempotency-key contract. A timeout after sending a write leaves its result uncertain. Re-read the resource or invitation history before retrying. Creation can duplicate records, visibility toggles can reverse state again, and invitation/resend operations can queue another email. Order lifecycle replay guards apply only to their individual operations.

Apply writes one at a time when they depend on each other. Preserve the event relationship, follow any returned replacement order ID, and refresh affected records after success. Do not retry invalid credentials, foreign IDs or validation errors without correcting the request.

Understand the contract boundary

The reference describes existing implementation, including its legacy response formats. Successful writes were reviewed in source; documentation discovery exercised synthetic reads and deliberately rejected writes. It did not send invitations, change payment state or check customers in. Test successful writes with synthetic data in your own authorized environment before enabling them.

Public waiting-list signup, provider refunds, company promotion forms, stage editing and CSV imports also exist as application workflows. Their HTML/session requirements are described in the relevant guides; no standalone JSON contract is implied by an organizer form or a controller name.