API-referanse

Dette er den komplette API-referansen for Billettsalg-backend. Alle endepunkter betjenes av Azure Functions under /api-prefikset, og autentisering skjer via JWT bearer-tokener med mindre annet er angitt.

Merking av testdata for rapportering

GET|PATCH /event-history/{kind}/{id}/reporting-classification?organizationId={organizationId}, der kind er normal eller shared, bruker kanonisk eiermyndighet og kontrollerte koblinger til lokale projeksjoner. Bare en godkjent administrator i eierorganisasjonen eller en superadmin med organisasjonsavgrenset tilgang kan bruke endepunktet. Imitasjon, andre roller og tilgang som bare deltaker avvises. Nye merkinger krever at arrangementet oppfyller livsløpskravene for historikk. Etter gjenoppretting kan eksisterende merking fortsatt fjernes uten en ny livsløpsendring. En identisk, fullført operasjon kan gjentas etter at merkingen er fjernet, men ny merking av et aktivt arrangement avvises.

GET returnerer { isTestData, revision, audit, canMark }. Aktive arrangementer uten merkingshistorikk gir 404. Aktive arrangementer med merkingshistorikk beholder loggtilgang med canMark: false, også etter at merkingen er fjernet. Loggen inneholder de siste 50 uforanderlige endringene med operasjons-ID, bruker-ID, UTC-tidspunkt, tidligere og ny merking og revisjon. Kvitteringsidentitet, påkrevde felt, sammenheng mellom revisjonene og samsvar med gjeldende merking kontrolleres. PATCH godtar nøyaktig { isTestData: boolean, expectedRevision: number, operationId: UUID }. Bruk samme operasjons-ID og innhold på nytt ved ubekreftet svar. Gjenbruk med annet innhold gir konflikt. Samtidige endringer gir 409 EVENT_REPORTING_CONFLICT og krever oppdatering og ny bekreftelse.

Manglende metadata betyr vanlig rapportering bare når containeren er bekreftet tilgjengelig, også når SDK-et returnerer status 404 uten å kaste en feil. Manglende eller uavklart lagring og ugyldig loggdokumentasjon gir 503 EVENT_REPORTING_UNAVAILABLE. Vanlige arrangementer bruker identiteten organization:{organizationId}/event:{eventId}. Delte arrangementer bruker den kanoniske identiteten shared:{sharedEventId}/event, og delegerte arrangementer bruker eierens identitet. Cosmos-containeren eventReporting har partisjonsnøkkel /scopeKey, ingen TTL og delt databasekapasitet. Gjeldende merking og uforanderlig loggkvittering skrives i én betinget transaksjon. Arrangementer, bestillinger, fakturaer, registreringer og oppgjør endres ikke. Containeren må opprettes før koden distribueres. Utilgjengelig lagring gir feil, ikke en antakelse om vanlig rapportering.

Vanlige rapporter og eksporttotaler utelater merkede arrangementer. Et uttrykkelig rapportvalg gir 409 EVENT_EXCLUDED_TEST_DATA etter vanlig autorisasjon. Eksisterende arkivbegrensninger gjelder fortsatt. Historisk rapportmodus bevarer beløpene med historicalEvent.isTestData og eksisterende eksportforbud. Både personlig arrangementshistorikk og historikk for ansatte beholder merkede oppføringer med isTestData, inkludert kanonisk merking av delte arrangementer og eierens merking av delegerte arrangementer. Bare autoriserte ansattvisninger gir canManageReportingClassification. Medlemmer får ingen merkingslogg eller kontroller for å endre merkingen. Funksjonen avslutter ikke operative arrangementer og avklarer ikke andre rapporterte økonomiske avvik.

API-konvensjoner

Disse konvensjonene gjelder på tvers av alle endepunkter. De gjør det enklere å integrere mot API-et.

Responskonvolutt

Alle endepunkter returnerer en konsekvent JSON-konvolutt — sjekk success først, og les deretter data eller error:

{ "success": true, "data": T }
{ "success": false, "error": "string", "message": "string" }

Organisasjonsavgrensing

De fleste autentiserte endepunkter krever en ?organizationId={organizationId}-queryparameter. Middleware bruker denne til å slå opp innringerens medlemskap og rolle i den aktuelle organisasjonen. Manglende parameter er en vanlig årsak til 400-feil.

Paginering

Listeendepunkter som kan returnere store datamengder støtter queryparameteren limit og returnerer en continuationToken for markørbasert paginering. Send tokenet som ?continuationToken={value} for å hente neste side.

Ratebegrensning

Autentiseringsendepunktene magic-link og verify håndhever ratebegrensning per IP for å hindre misbruk. Ratebegrensning er aktivert i alle miljøer og kan ikke omgås av sikkerhetshensyn.

Myk sletting

Arrangementer, registreringer og brukere støtter myk sletting via et deletedAt-tidsstempel. Mykt slettede poster utelates fra vanlige spørringer, men kan gjenopprettes av en admin.

Autentisering

Metode	Endepunkt	Beskrivelse	Autent.
POST	/api/auth/magic-link	Be om innloggings-e-post	Offentlig
POST	/api/auth/verify	Verifiser magic link-token	Offentlig
POST	/api/auth/verify-code	Verifiser 6-sifret kode fra e-post	Offentlig
GET	/api/auth/me	Hent gjeldende bruker	Påkrevd

Arrangementer

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/events	List alle arrangementer	Påkrevd
GET	/api/events-active	Hent aktivt arrangement	Påkrevd
GET	/api/events-overview	Hent arrangementer med statistikk	Påkrevd
GET	/api/events/{id}	Hent arrangementsdetaljer	Påkrevd
POST	/api/management/events	Opprett arrangement	Admin
PUT	/api/management/events/{id}	Oppdater arrangement	Admin
DELETE	/api/management/events/{id}	Mykt slett arrangement	Admin
PATCH	/api/management/events/{id}/restore	Gjenopprett mykt slettet arrangement	Admin
PUT	/api/management/events/{id}/lock	Slå av eller på salgslås	Admin

Oppretting, oppdatering, salgslås, myk sletting, gjenoppretting og registrering av eksternt salg på et eid arrangement krever i tillegg en full organisasjon. En sellingPartner-organisasjon får 403 ORG_MODE_RESTRICTED før noe skrives. Se Organisasjonens kapabilitetsmodus.

enableQuotas-felt

Forespørselskroppen for oppretting og oppdatering av arrangement aksepterer et valgfritt enableQuotas-felt (boolean). Når feltet er true, håndheves tildelingsgrenser når bestillinger opprettes for arrangementet. Standard er false.

Delte arrangementer

Endepunktene for delte arrangementer bruker samme JWT- og ?organizationId={organizationId}-konvensjoner som resten av API-et. Azure Functions-utløseren er konfigurert som anonym, men hver handler utfører autentisering og autorisasjon i applikasjonen. Oppretting og endringer krever også SHARED_EVENTS_ENABLED=true. En konfigurert organisasjonstillatelsesliste kan begrense hvem som kan gjøre endringer.

Rollebetegnelsene nedenfor oppsummerer de effektive tilgangskontrollene. Navngitte rettighetstildelinger kan delegere bestemte oppgaver uten å gi en bredere organisasjonsrolle.

Grunnleggende endepunkter og invitasjoner

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/shared-event-capabilities/create	Sjekk om gjeldende organisasjon kan opprette delte arrangementer	Organisasjonsadmin
POST	/api/shared-events	Opprett et delt arrangement som utkast	Organisasjonsadmin eller superadmin
GET	/api/shared-events	List delte arrangementer for gjeldende organisasjon. scope=all er bare for superadmin	Deltakermedlem eller superadmin
GET	/api/shared-events/{sharedEventId}	Hent visningen innringeren har tilgang til	Deltakermedlem, invitert leser eller superadmin
GET	/api/shared-events/{sharedEventId}/capacity	Les autoritativ kapasitet for delt arrangement	Deltakermedlem eller superadmin
GET	/api/shared-event-invitations/pending	List invitasjoner for organisasjoner innringeren administrerer	Autentisert organisasjonsadmin
POST	/api/shared-event-invitations/pending/accept	Godta en invitasjon i appen	Admin i mottakende organisasjon
GET	/api/shared-event-invitations/preview	Forhåndsvis en lenkeinvitasjon uten å røpe detaljer om ugyldige tokener	Autentisert
POST	/api/shared-event-invitations/accept	Godta en lenkeinvitasjon	Admin i mottakende organisasjon
POST	/api/shared-events/{sharedEventId}/invitation-links	Opprett en invitasjonslenke og forsøk eventuelt e-postlevering	manageParticipants og organisasjonsadmin
GET	/api/shared-events/{sharedEventId}/invitation-links	List invitasjonsmetadata. Tokenhash returneres aldri	manageParticipants
DELETE	/api/shared-events/{sharedEventId}/invitation-links/{linkId}	Tilbakekall en invitasjonslenke	manageParticipants og organisasjonsadmin
POST	/api/shared-events/{sharedEventId}/participants/{orgId}/accept	Godta en deltakerinvitasjon	Admin i målorganisasjonen
POST	/api/shared-events/{sharedEventId}/participants/{orgId}/decline	Avslå en deltakerinvitasjon	Admin i målorganisasjonen
POST	/api/shared-events/{sharedEventId}/participants/{orgId}/leave	Forlat et delt arrangement	Admin i målorganisasjonen

Ugyldige, utløpte, brukte, tilbakekalte eller utilgjengelige invitasjoner returnerer generiske ikke-funnet-svar slik at innringere ikke kan undersøke invitasjonsstatus.

Oppretting av delte arrangementer og alle veier for å bli med krever en full organisasjon. Begrensede sellingPartner-organisasjoner utelates fra søk etter deltakere og får 403 ORG_MODE_RESTRICTED før en delt arrangementsprojeksjon skrives. Avslag, uttreden, fjerning og nødvendige leseruter forblir åpne, slik at modusen aldri låser en organisasjon fast i et delt arrangement.

Administrasjon for arrangør og deltakere

Metode	Endepunkt	Beskrivelse	Autent.
PATCH	/api/shared-events/{sharedEventId}	Rediger felles detaljer eller priser	Organisasjonsadmin med manageSharedDetails eller managePricing
PATCH	/api/shared-events/{sharedEventId}/capacity	Rediger felleskapasitet	Superadmin
DELETE	/api/shared-events/{sharedEventId}	Avslutt et utkast på en sikker måte	Superadmin
POST	/api/shared-events/{sharedEventId}/participants	Legg en organisasjon direkte til deltakerlisten	Superadmin
DELETE	/api/shared-events/{sharedEventId}/participants/{orgId}	Fjern en deltaker	Organisasjonsadmin med manageParticipants
PATCH	/api/shared-events/{sharedEventId}/lifecycle	Flytt arrangementet mellom tillatte livssyklusstatuser	Organisasjonsadmin med manageSharedDetails
PATCH	/api/shared-events/{sharedEventId}/participants/{orgId}/quota	Oppdater kvoten for én deltaker	manageCapacity
PATCH	/api/shared-events/{sharedEventId}/quotas	Oppdater deltakerkvoter samlet	manageCapacity
POST	/api/shared-events/{sharedEventId}/capacity-policy	Endre kapasitetsmodell gjennom den beskyttede overgangsprosessen	manageCapacity
GET	/api/shared-events/{sharedEventId}/participants/{orgId}/users	List aktuelle brukere for eier- eller rettighetsadministrasjon	Organisasjonsadmin med manageOwners, eller superadmin
PUT	/api/shared-events/{sharedEventId}/grants/{granteeUserId}	Opprett eller oppdater en navngitt rettighetstildeling	Organisasjonsadmin med manageOwners
DELETE	/api/shared-events/{sharedEventId}/grants/{granteeUserId}	Tilbakekall en navngitt rettighetstildeling	Organisasjonsadmin med manageOwners
GET	/api/shared-events/{sharedEventId}/audit	Les den paginerte revisjonsloggen	Autorisert deltaker eller superadmin

Rapportering, salgskanaler og driftsendepunkter

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/shared-events/{sharedEventId}/reports/combined	Hent samlet arrangementsrapport	Eier, viewCombinedReports eller superadmin
GET	/api/shared-events/{sharedEventId}/reports/participant	Hent deltakerrapport. Standard er innringerens organisasjon	Deltaker for egen organisasjon. Eier eller superadmin for tillatt mål
GET	/api/shared-events/{sharedEventId}/external-sales-channels	List eksterne salgskanaler med beskyttede referanser skjult	Deltakermedlem, medlem i invitert organisasjon eller superadmin
GET	/api/shared-events/{sharedEventId}/external-sales-channels/{source}	Hent én ekstern salgskanal med beskyttede referanser skjult	Deltakermedlem, medlem i invitert organisasjon eller superadmin
PUT	/api/shared-events/{sharedEventId}/external-sales-channels/{source}	Tildel eller oppdater ansvarlig deltakerorganisasjon	manageExternalSales og organisasjonsadmin
DELETE	/api/shared-events/{sharedEventId}/external-sales-channels/{source}	Deaktiver en kanal uten å slette historisk tilordning	manageExternalSales og organisasjonsadmin
GET	/api/shared-event-organizations/search	Søk etter aktive organisasjoner for direkte deltaker- eller salgspartneradministrasjon	Superadmin
POST	/api/shared-events/{sharedEventId}/operation-status	Oppdater gjenopprettingsstatus og utfør projeksjonsarbeid i kø	Autorisert deltaker eller superadmin
POST	/api/shared-events/{sharedEventId}/sync-projections	Be om reparasjon eller synkronisering av organisasjonsprojeksjoner	Organisasjonsadmin med manageSharedDetails

Organisasjonssøk, rettighetstildeling, operasjonsstatus og projeksjonssynkronisering er administrative eller driftsrettede endepunkter for administrasjonsgrensesnittet. De er ikke offentlige søke-API-er og erstatter ikke arbeidsflytene for arrangører og deltakere.

Organisasjonssøket aksepterer purpose=sharedEvent eller purpose=delegatedSales. Standardverdien sharedEvent utelater begrensede organisasjoner. delegatedSales inkluderer dem fordi de er den tiltenkte målgruppen for salgspartnerinvitasjoner. Responsen røper aldri organisasjonsmodus.

Kanalendepunktene gir også autentiserte medlemmer i en invitert organisasjon en begrenset lesetilgang før invitasjonen er godtatt. De mottar bare kanaloppsettet. Beskyttede connectionRef-verdier fjernes. Aktive deltakere får samme skjerming med mindre kanalen er tildelt deres egen organisasjon. Eiere og superadministratorer kan motta de beskyttede referansene. Innringere utenfor deltakerorganisasjonene og inviterte organisasjoner avvises.

Delegert salg (salgspartnere)

Delegert salg lar en arrangementseier gi en annen organisasjon en avgrenset, selvbetjent mulighet til å selge billetter på sine vegne for et vanlig (ikke delt) arrangement, uten rett til å kansellere en godkjent eller levert bestilling, refundere, overføre, avstemme, fakturere, arkivere eller konfigurere arrangementet. Dette er ikke det samme som medeierskap i et delt arrangement. Se Datamodell → Delegert salg for det fullstendige feltnivå-skjemaet.

Fra og med v1.2.0 er hovedflyten for kjøperen selvbetjening: et godkjent medlem av partnerorganisasjonen bestiller det delegerte arrangementet gjennom den vanlige bestillingsflyten for medlemmer, bestillingen opprettes som pending, og partnerorganisasjonens egen billettansvarlig+ godkjenner og leverer den gjennom en godkjenningskø. Katalogsynlighet og bestillingsoppretting styres hver for seg av sin egen utrullingsbryter — se Miljøvariabler → Konfigurasjon for delegert medlemsbestilling. Et ansatt-opprettet (på vegne av) bestillingsendepunkt beholdes som en sekundær, kompatibel løsning for tilfeller selvbetjening ikke dekker.

Endepunkter for eiersiden

Metode	Endepunkt	Beskrivelse	Autent.
POST	/api/organizations/{organizationId}/events/{eventId}/sales-delegations	Inviter en partnerorganisasjon til å selge billetter for arrangementet	Eierorganisasjonens admin+
GET	/api/organizations/{organizationId}/events/{eventId}/sales-delegations	List delegeringer for arrangementet	Eierorganisasjonens admin+
POST	/api/organizations/{organizationId}/events/{eventId}/sales-delegations/{delegationId}/revoke	Tilbakekall en invitert eller aktiv delegering	Eierorganisasjonens admin+

POST .../sales-delegations — inndata for å finne partneren er rollestyrt og gjensidig utelukkende. Forespørselskroppen aksepterer nøyaktig ett av to felt; målorganisasjonen løses alltid opp på serversiden til slutt, aldri som fritekst fra klienten:

Felt	Type	Hvem kan sende det	Beskrivelse
partnerAdminEmail	string (e-post)	Alle innringere	E-postadressen til en administrator i målorganisasjonen. Serveren løser den opp til nøyaktig én kvalifisert organisasjon via resolvePartnerOrganizationByAdminEmail (api/src/shared/delegation-partner-resolution.ts), som gjenbruker samme omvendte oppslag som invitasjoner til delte arrangementer.
partnerOrganizationId	string	Kun superadmin	En rå organisasjons-ID, kun beregnet på den superadmin-only organisasjonssøkeflyten (GET /shared-event-organizations/search) — aldri en verdi en vanlig admin-klient skal konstruere eller sende.

{ "partnerAdminEmail": "admin@partner-choir.example" }

{ "partnerOrganizationId": "org-id-fra-sokeresultat" }

Å sende begge feltene, eller ingen av dem, feiler skjemavalidering og returnerer HTTP 400 (Provide exactly one of partnerOrganizationId or partnerAdminEmail) — det finnes ingen prioriteringsregel mellom de to.

En vellykket invitasjon (uansett vei) returnerer HTTP 201 med et objekt som inneholder delegation, en invitationLink (engangslenke — bare hashen av tokenet lagres, så lenken kan ikke hentes ut igjen etter dette svaret) og reverseIndexSync-status.

• Å invitere en partnerorganisasjon som allerede har en invited- eller active-delegering for arrangementet, er idempotent: den eksisterende delegeringen (og lenken, hvis fortsatt tilgjengelig) returneres i stedet for å opprette en duplikat.
• Kvalifisering for begge veier: den oppløste målorganisasjonen må være aktiv (ikke slettet) og kan ikke være innringerens egen organisasjon. Det finnes ingen egen partnerskaps-godkjenningsprosess utover dette.

Feilkoder spesifikke for oppslag av partner:

• 400 — Både partnerAdminEmail og partnerOrganizationId er til stede, eller ingen av dem er det (skjemavalideringsfeil).
• 400 — partnerOrganizationId løses opp til innringerens egen organisasjon (Cannot delegate sales to your own organization), eller til en projeksjon av et delt arrangement.
• 403 — partnerOrganizationId sendt av en innringer som ikke er superadmin. Dette er en hard rollesperre, uavhengig av om ID-en ellers ville vært gyldig — en vanlig eieradmin kan aldri bruke dette feltet til å utforske organisasjons-ID-er.
• 404 — partnerAdminEmail kunne ikke løses opp til nøyaktig én kvalifisert partnerorganisasjon. Dette ene generiske utfallet (samme melding som «No partner organization could be invited with that email address», med ekstra tidsvariasjon i responsen) returneres identisk enten adressen er ukjent, tilhører en som ikke er admin, bare tilhører en ikke-kvalifisert/slettet organisasjon, bare tilhører innringerens egen organisasjon, eller er administrator for mer enn én kvalifisert organisasjon (tvetydig mål) — anti-enumereringskontrakten gjør disse bevisst umulige å skille fra hverandre for innringeren. Frontend utdyper eller tolker aldri denne meldingen videre.

POST .../sales-delegations/{delegationId}/revoke aksepterer { "revokedReason": "..." } — revokedReason er påkrevd og kan ikke være tom. Å tilbakekalle en allerede tilbakekalt delegering er idempotent. Tilbakekalling trer i kraft umiddelbart mot eierens autoritative Event.salesDelegations[], uavhengig av hvor raskt partnerens egen omvendte indeks henger med — partneren mister umiddelbart retten til å opprette bestillinger, godkjenne/levere og rapportere, selv før egen liste eller katalogprojeksjon er oppdatert.

Endepunkter for aksept på partnersiden

Metode	Endepunkt	Beskrivelse	Autent.
POST	/api/sales-delegations/accept	Godta en invitasjon med tokenet fra engangsinvitasjonslenken	Partnerorganisasjonens admin+
POST	/api/organizations/{partnerOrganizationId}/sales-delegations/{delegationId}/decline	Avslå en ventende invitasjon	Partnerorganisasjonens admin+

POST .../decline krever ikke noe token — det er en handling i appen, gyldig bare fra status invited, og er idempotent hvis delegeringen allerede er avslått.

Endepunkter for medlemmenes selvbetjening og partnerens rapportering

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/organizations/{partnerOrganizationId}/delegated-events	List arrangementer som for øyeblikket er delegert til denne organisasjonen	Ethvert godkjent medlem av partnerorganisasjonen
GET	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/sales-context	Hent salgbare forestillinger og billetttyper uten eierens kapasitet	Billettansvarlig+
GET	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/sales-summary	Hent partneravgrensede data for Oversikt og Rapporter under gjeldende delegering	Billettansvarlig+
POST	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/orders/self	Selvbetjening: oppretter en pending-bestilling for den autentiserte innringeren	Ethvert godkjent medlem av partnerorganisasjonen
POST	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/orders/{orderId}/cancel	Kanseller en pending-bestilling — av kjøperen selv, eller av partnerens egen billettansvarlig+ på kjøperens vegne	Kjøper, eller billettansvarlig+
GET	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/orders/queue	Partnerens godkjenningskø for egne medlemmers selvbetjente bestillinger, filtrerbar på status pending eller approved	Billettansvarlig+
POST	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/orders/{orderId}/approve	Godkjenn en ventende selvbetjent bestilling	Billettansvarlig+
POST	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/orders/{orderId}/deliver	Merk en godkjent bestilling som levert	Billettansvarlig+
POST	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/orders/{orderId}/approve-and-deliver	Godkjenn og lever en ventende bestilling i ett steg	Billettansvarlig+
GET	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/orders	List denne partnerorganisasjonens egne bestillinger for arrangementet	Billettansvarlig+
POST	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/orders/{orderId}/report-sold	Rapporter solgt antall på en delegert bestilling	Billettansvarlig+, eller kjøperen for egen bestilling
POST	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/orders/{orderId}/report-returned	Rapporter returnert antall på en delegert bestilling	Billettansvarlig+, eller kjøperen for egen bestilling
POST	/api/organizations/{partnerOrganizationId}/delegated-events/{eventId}/orders	Utfaset, beholdt som sekundær løsning. Ansatt-opprettet (på vegne av) bestilling for et godkjent medlem av partnerens egen organisasjon, opprettet allerede delivered uten godkjenningssteg	Billettansvarlig+

• GET .../delegated-events returnerer bare referanser med denormalisert status "active" — inviterte, avslåtte og tilbakekalte delegeringer vises aldri i denne listen.
• GET .../sales-context returnerer arrangementsidentitet, salgslås, salgbare forestillinger og billetttyper. Eierens salskapasitet og gjenstående kapasitet på tvers av kanaler er bevisst utelatt. Kapasitet håndheves autoritativt ved skriving, og konfliktsvar til partneren røper ikke eierens eller andre partneres salg.
• GET .../sales-summary løser eierorganisasjonen og den gjeldende aktive delegeringen på serversiden og gjør et partisjonsfestet oppslag etter partnerens bestillinger under denne delegeringen. Responsen inneholder livssyklustotaler, fordeling per billetttype og forestilling, rader for nåværende godkjente medlemmer, operativ bestillingsdetalj, bruttoinntekt og en maskinlesbar avgrensningskontrakt. Den utelater eierens direktesalg, andre partnere, eksternt salg, kapasitet, kontaktopplysninger, notater, fakturastatus, arrangørkontroller, Cosmos-metadata og fortsettelsestokener. Hvis gjeldende medlemskap ikke beviser identiteten, returneres raden uten attribusjon. Kansellerte bestillinger bidrar ikke til solgt, returnert, utestående eller inntekt. Bruttoinntekt er ikke kompensasjon, nettooppgjør, fakturert beløp eller betalingsstatus. Partnereksport er ikke tilgjengelig.
• POST .../orders/self krever en active-delegering og de samme levende sjekkene som enhver annen delegert skriveoperasjon. Den vanlige POST /api/orders-ruten er ubetinget stengt for et arrangement med en delegert projeksjon — den avvises der med en feilmelding om feil endepunkt, uavhengig av rolle eller projeksjonstilstand, slik at en delegert bestilling aldri kan bygges mot feil organisasjons kapasitetsregnskap. Når DELEGATED_MEMBER_ORDERING_ENABLED er av, returnerer dette endepunktet HTTP 503 med feilkoden DELEGATED_MEMBER_ORDERING_UNAVAILABLE og oppretter ingenting.
• POST .../orders/{orderId}/cancel kan bare flytte en pending-bestilling til kansellert — samme regel som for en vanlig medlemsbestilling. En partner-billettansvarlig+ får ikke eieradministratorens mulighet til å kansellere en bestilling som allerede er godkjent eller levert.
• GET .../orders/queue og handlingene approve / deliver / approve-and-deliver er avgrenset til bestillinger opprettet under partnerens egen, for øyeblikket aktive delegering for dette arrangementet; de returnerer eller handler aldri på eierens egne bestillinger eller en annen partners bestillinger. Alle tre verifiserer delegeringen på nytt ved hvert kall, slik at en delegering som tilbakekalles midt i en økt, umiddelbart blokkerer videre handling, selv på bestillinger som allerede ligger i køen.
• Det ansatt-opprettede endepunktet POST .../orders krever at kjøperen er et godkjent medlem av partnerens egen organisasjon (aldri eierens medlemmer eller en annen partners medlemmer), og oppretter bestillingen allerede med status delivered, soldQuantity: 0 og returnedQuantity: 0. En kapasitetskonflikt ved innsending avvises med HTTP 409 CAPACITY_EXCEEDED.
• GET .../orders er avgrenset server-side til soldByOrganizationId === partnerOrganizationId; den returnerer aldri eierens egne bestillinger eller en annen partners bestillinger, og utelater denne partnerens bestillinger som siden er overført bort fra den.
• POST .../report-sold og POST .../report-returned verifiserer på nytt, ved hvert kall, at innringerens organisasjon fortsatt har en aktiv delegering for arrangementet og fortsatt har salgsmyndighet over den spesifikke bestillingen — en delegering som tilbakekalles midt i en økt, blokkerer umiddelbart videre rapportering, selv på bestillinger som allerede er opprettet. Rapporter-solgt håndhever samme atomiske kapasitetssperre som eiersidens rapportering. Rapporter-returnert speiler eiersidens returregel nøyaktig: kravet om at arrangementet/forestillingen må være avsluttet, gjelder alltid for et medlem som returnerer sin egen delegerte bestilling, akkurat som ved en vanlig egen-organisasjons-retur. Dette kravet fravikes bare for partnerens egen billettansvarlig+ som registrerer en retur på et medlems vegne.

Hva delegert salg aldri eksponerer

Ingen delegert-salg-endepunkt støtter refusjon, overføring, avstemming, oppgjør, fakturering eller arkivering av en bestilling, endring av arrangements-, pris-, billettype- eller kapasitetskonfigurasjon, eller kansellering av en bestilling som allerede er godkjent eller levert. Dette forblir utelukkende hos eiersidens endepunkter, avgrenset til eierorganisasjonens egne roller. Den delegerte projeksjonen som gjør en konsert synlig i partnerens egen katalog, er kun en visningsindeks — den brukes aldri i en autorisasjonsvurdering; hver skriveoperasjon utleder autoritet på nytt fra eierens levende Event.salesDelegations[].

Bestillinger

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/orders	List bestillinger (med filtre)	Billettansvarlig+
POST	/api/orders	Opprett bestilling	Medlem+
GET	/api/orders/{id}	Hent bestillingsdetaljer	Billettansvarlig+
POST	/api/orders/{id}/approve	Godkjenn bestilling	Billettansvarlig+
POST	/api/orders/{id}/deliver	Marker bestilling som levert	Billettansvarlig+
POST	/api/orders/{id}/cancel	Kanseller bestilling	Billettansvarlig+
DELETE	/api/orders/{id}	Slett bestilling	Billettansvarlig+
PATCH	/api/orders/{id}/archive	Arkiver eller gjenopprett bestilling	Billettansvarlig+
POST	/api/orders/archive/preview	Forhåndsvis kvalifiserte fullførte bestillinger for ett arrangement	Billettansvarlig+
POST	/api/orders/archive	Arkiver én gruppe kvalifiserte fullførte bestillinger for ett arrangement	Billettansvarlig+
PATCH	/api/orders/{id}/admin-note	Oppdater adminnotat på bestilling	Billettansvarlig+
POST	/api/orders/{id}/transfer	Overfør bestilling til et annet medlem	Billettansvarlig+
GET	/api/me/orders	Hent gjeldende brukers bestillinger	Medlem+

Begge de arrangementsspesifikke arkivendepunktene aksepterer { "eventId": "..." }. En kansellert bestilling er kvalifisert. En oppgjort bestilling er bare kvalifisert når den har et gyldig, låst invoiceBasis og invoicedAt. Slettede og allerede arkiverte bestillinger utelates. Forhåndsvisningen returnerer eligibleCount, statusBreakdown, blockedSettledUninvoiced og blockedInvalidInvoiceBasis. Arkivendepunktet bruker samme kandidatregel, overstyrer aldri blokkeringer, behandler maksimalt 100 bestillinger per kall og returnerer de to blokkeringstallene sammen med processed, conflicts, skipped, remaining, hasMore og completed.

Hvis en uventet feil oppstår etter at minst én bestilling er varig arkivert, returnerer endepunktet HTTP 207 med success: true og completed: false i data i stedet for å forkaste fremdriften. Resultatet inneholder de varige tellerne samt avgrensede verdier for failureCode og failureReason. remaining er numerisk når den etterfølgende opptellingen lykkes, eller null når antallet ikke kan fastslås; hasMore forblir true når antallet er ukjent. Klienter må ikke prøve denne mutasjonen automatisk på nytt, fordi hvert vellykkede kall endrer kandidatene for neste kall.

Arkivering beholder livssyklus, salg, returer, avstemming, fakturastatus og økonomiske opplysninger. Det individuelle PATCH-endepunktet aksepterer { "archived": true | false }. Organisasjonsadministratorer kan uttrykkelig overstyre en blokkert oppgjort bestilling med { "archived": true, "override": { "confirmed": true } }. Billettansvarlige og kasserere får 403 ARCHIVE_OVERRIDE_FORBIDDEN; vanlige blokkerte forespørsler får 409 INVOICE_REQUIRED eller INVALID_INVOICE_BASIS. Overstyringsbeviset lagrer aktør, visningsnavn, tidspunkt, arkiveringstidspunkt og nøyaktige blokkeringer. Beviset beholdes etter gjenoppretting. Eldre arkiverte bestillinger forblir arkivert, men de nye kravene gjelder etter gjenoppretting.

Livssyklus for trykte billetter

Metode	Endepunkt	Beskrivelse	Autent.
POST	/api/orders/{id}/report-sold	Registrer det nye, samlede antallet solgt fra en levert bestilling	Bestillingseier eller admin
POST	/api/orders/{id}/return	Registrer en trinnvis retur av usolgte trykte billetter	Bestillingseier eller billettansvarlig+
POST	/api/orders/{id}/approve-reconciliation	Godkjenn en fullstendig avstemt bestilling og lås fakturagrunnlaget	Billettansvarlig+

POST /api/orders/{id}/report-sold aksepterer:

{
  "soldQuantity": 4,
  "soldTypeQuantities": [
    { "ticketTypeId": "adult", "soldQuantity": 2 }
  ]
}

soldQuantity er det nye, absolutte totalantallet solgt for bestillingen. Hvert valgfritt antall per billettype er antallet som ble solgt i denne forespørselen, og summen per type må være lik økningen fra forrige total. Bestillingen må være levert, innringeren må eie den eller være admin, og det nye totalantallet kan ikke overstige bestilt antall minus returer. Den lokale kontrollen av salskapasitet returnerer HTTP 409 med errorCode: "CAPACITY_EXCEEDED", data.availableCapacity og data.requestedDelta. Konflikter fordi et delt arrangement er utsolgt eller kapasiteten er fryst, kan returnere samme HTTP-status og feilkode uten kapasitetsfeltene. Et vellykket svar returnerer den oppdaterte bestillingen i data.

POST /api/orders/{id}/return aksepterer:

{
  "returnQuantity": 2,
  "returnTypeQuantities": [
    { "ticketTypeId": "adult", "returnQuantity": 2 }
  ]
}

Returantallet og valgfrie verdier per billettype er trinnvise. De kan ikke overstige utestående antall. Medlemmer kan bare returnere egne billetter og først etter at den aktuelle forestillingen eller arrangementet er avsluttet. Billettansvarlige, kasserere, administratorer og superadministratorer kan registrere en retur på vegne av et medlem uten datobegrensningen. Bestillingen forblir delivered mens billetter er utestående og går til awaitingReconciliation når solgt pluss returnert er lik bestilt antall.

POST /api/orders/{id}/approve-reconciliation krever ingen forespørselskropp. Endepunktet godtar bare en bestilling med status awaitingReconciliation der solgt pluss returnert er lik utlevert antall. Godkjenning endrer status til settled, registrerer godkjenneren og lagrer et uforanderlig fakturagrunnlag.

Grunnlaget inneholder bare solgt antall multiplisert med enhetsprisene som ble lagret med bestillingen. Hvis alle billetter ble solgt, kan eldre bestillinger utlede antall per type fra de bestilte antallene. Hvis ingen billetter ble solgt, blir grunnlaget tomt med verdi null. Et delvis salg krever fullstendige og konsistente soldTypeQuantities, samt konsistente returdetaljer per type når de finnes. Ufullstendig eller selvmotsigende delhistorikk returnerer 400 og blokkerer oppgjør. totalAmount brukes aldri som reserve for fakturagrunnlaget.

Godkjenningen setter ikke invoicedAt og oppretter eller sender ikke en faktura. Et vellykket svar returnerer den oppgjorte bestillingen i data.

Feil i livssyklusen bruker standard feilkonvolutt. Forvent 400 ved ugyldige antall eller statuser, 403 ved feil eierskap eller rolle, 404 for ukjent bestilling, 409 ved kapasitetskonflikt og 503 når kapasiteten for et delt arrangement er midlertidig utilgjengelig.

Overføring av bestillinger

Overføringsendepunktet lar billettansvarlige flytte billetter mellom medlemmer — enten ved å tildele hele bestillingen på nytt, eller ved å dele den i en kilde- og en mottakerbestilling. En delvis overføring gjennomføres som én atomisk Cosmos-transaksjonsbatch innenfor samme organisasjonspartisjon (erstatt kilde, opprett mottaker), og hver forespørsel er idempotent per klientoppgitt transferRequestId, slik at en gjentatt eller reprodusert forespørsel aldri kan duplisere en overføring eller la den ene siden oppdateres uten den andre.

Metode	Endepunkt	Beskrivelse	Autent.
POST	/api/orders/{id}/transfer	Overfør hele eller deler av en bestilling til et annet medlem	Billettansvarlig+

POST /api/orders/{id}/transfer aksepterer:

{
  "toUserId": "user-id-of-destination",
  "transferRequestId": "550e8400-e29b-41d4-a716-446655440000",
  "tickets": [
    { "ticketTypeId": "adult", "quantity": 2 },
    { "ticketTypeId": "child", "quantity": 1 }
  ],
  "reason": "Member requested swap"
}

Hva som kan overføres (kun utestående):

En overføring kan bare flytte utestående (ikke rapportert) billettantall — enheter som ennå ikke er solgt eller returnert, er de eneste som er kvalifisert. Solgte og returnerte enheter, og tilhørende bevis per billetttype, flyttes eller endres aldri av dette endepunktet. Utestående beregnes som max(0, totalQuantity - effectiveSoldQuantity - returnedQuantity). Hvis forespurt antall overstiger det som er utestående — samlet eller for en enkelt billetttype — avvises forespørselen med TRANSFER_EXCEEDS_OUTSTANDING; hvis ingenting er utestående i det hele tatt, avvises den med TRANSFER_BLOCKED_NO_OUTSTANDING. Dette betyr at en forespørsel om å overføre hele bestillingen naturlig mislykkes så snart noe rapportering har skjedd (utestående er da mindre enn totalQuantity), mens en delvis overføring av den gjenværende utestående saldoen fortsatt lykkes.

Avstemming ved siste utestående overføring:

Hvis en delvis overføring flytter hele den gjenværende utestående saldoen på en delivered-kildebestilling (altså sourceRemainingQuantity blir 0), går kildebestillingens status fra delivered til awaitingReconciliation som en del av samme atomiske batch — akkurat som om de siste billettene var rapportert solgt eller returnert i stedet for overført. En full overføring utløser aldri dette, siden hele bestillingen tildeles på nytt (det er ingen redusert bestilling igjen å avstemme).

Feilkoder:

• 400 TRANSFER_EXCEEDS_OUTSTANDING — Forespurt antall overstiger det som er utestående på kildebestillingen.
• 409 TRANSFER_BLOCKED_NO_OUTSTANDING — Kildebestillingen har null utestående antall igjen — alt er allerede solgt eller returnert.
• 409 TRANSFER_REQUEST_ID_REUSED — Samme transferRequestId er allerede brukt til en overføring med en annen mottaker, modus eller andre antall.

Tildelinger (salgskvoter)

Tildelingsendepunkter administrerer billettkvoter per medlem. De brukes via arrangementets administrasjonspanel, ikke som en frittstående seksjon. Tildelingsgrenser håndheves kun når enableQuotas er true på det overordnede arrangementet.

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/allocations	List tildelinger	Billettansvarlig+
POST	/api/allocations	Opprett eller oppdater tildeling	Billettansvarlig+
DELETE	/api/allocations/{id}	Slett tildeling	Billettansvarlig+
GET	/api/allocations/members	List medlemmer med tildelingsoppsummering	Billettansvarlig+
GET	/api/my-allocations	Hent medlemmets egne tildelinger	Medlem+

Forpliktelser / løfter

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/events/{eventId}/my-pledge	Hent medlemmets eget løfte for arrangement	Medlem+
POST	/api/events/{eventId}/my-pledge	Send inn eller oppdater forpliktelsesløfte	Medlem+
GET	/api/events/{eventId}/pledge-summary	Hent samlet løfteoppsummering	Medlem+
GET	/api/management/events/{eventId}/pledges	List alle løfter for arrangement	Billettansvarlig+
PUT	/api/management/events/{eventId}/commitment	Åpne, lukk eller konverter forpliktelsesrunde	Admin

Eksternt salg

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/management/events/{eventId}/external-sales	List eksternt salg for arrangement	Billettansvarlig+
GET	/api/management/events/{eventId}/showtimes/{showtimeId}/external-sales	List eksternt salg per forestilling	Billettansvarlig+
POST	/api/management/events/{eventId}/ticketmaster-categories	Opprett gjenbrukbar, arrangementsspesifikk Ticketmaster-kategori	Billettansvarlig+
PUT	/api/management/events/{eventId}/ticketmaster-categories/{categoryId}	Rediger kategori med obligatorisk expectedVersion i forespørselskroppen	Billettansvarlig+
DELETE	/api/management/events/{eventId}/ticketmaster-categories/{categoryId}?version={version}	Slett nøyaktig kategorirevisjon	Billettansvarlig+
POST	/api/management/events/{eventId}/showtimes/{showtimeId}/external-sales	Opprett ekstern salgsoppføring	Billettansvarlig+
PUT	/api/management/external-sales/{id}	Oppdater eksternt salg	Billettansvarlig+
DELETE	/api/management/external-sales/{id}	Slett eksternt salg	Billettansvarlig+
POST	/api/management/external-sales/{id}/correction	Registrer administrativ korreksjon eller reversering	Admin

Gjenbrukbare kategorier lagres på arrangementet og oppretter aldri TicketType-dokumenter. Sletting fjerner bare den valgbare konfigurasjonen og frigjør straks én av de 50 kategoriplassene; eksisterende salgsøyeblikksbilder endres ikke. Synkronisering av en delt arrangementsprojeksjon beholder hver deltakerorganisasjons lokale kategorier og kopierer dem aldri til en annen deltaker.

Et salg kan i stedet ha én validert engangsetikett. En gjenbrukbar salgslinje må sende både customCategoryId og nøyaktig valgt customCategoryVersion. Manglende/slettet kategori eller revisjonskonflikt gir 409 TICKETMASTER_CATEGORY_REVISION_CONFLICT før kapasitetsobservasjon eller salgslagring. Begge variantene lagrer original etikett, valgfri kobling, Ticketmaster-pris/gebyr og kapasitetsvalg på salget. countsTowardCapacity er true som standard; capacityQuantity lagrer bidraget, mens eldre rader uten feltet fortsatt bruker totalQuantity. Koblingen gir et separat Ticketmaster-bidrag per billettype, men oppretter aldri beholdning eller et ekstra kapasitetsbidrag.

PUT /api/management/external-sales/{id} tillater bare endringer som ikke gjelder kilde. Lagret source er uforanderlig, så en forespørsel med source avvises i stedet for å omklassifisere raden til eller fra Ticketmaster.

Fribilletter

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/events/{eventId}/free-tickets	List fribilletter	Billettansvarlig+
POST	/api/events/{eventId}/free-tickets	Opprett fribillettoppføring	Billettansvarlig+
PUT	/api/events/{eventId}/free-tickets/{id}	Oppdater fribillettoppføring	Billettansvarlig+
DELETE	/api/events/{eventId}/free-tickets/{id}	Slett fribillett	Billettansvarlig+
GET	/api/events/{eventId}/capacity-summary	Hent kapasitetsoppsummering for arrangement	Påkrevd

Oppdateringsendepunktet krever ?organizationId={organizationId} og et ikke-tomt JSON-objekt med ett eller flere av feltene showtimeId, ticketTypeId, quantity, recipient og reason. Antall må være et positivt heltall. Hvis billettype eller forestilling endres, må den tilhøre arrangementet i URL-en. Svaret returnerer det oppdaterte fribillettobjektet i data.

For delte arrangementer reserverer og bekrefter en antallsøkning bare den ekstra kapasiteten. En reduksjon behandles som en administrativ korrigering og frigir ikke tidligere bekreftet felleskapasitet. Trygge feil omfatter ugyldig input eller utilgjengelig kapasitet, en manglende kobling mellom billett og arrangement, utilgjengelig salg for delt arrangement og midlertidig kapasitetsoppsett eller synkronisering.

Registreringer (direktesalg)

Metode	Endepunkt	Beskrivelse	Autent.
POST	/api/registrations	Opprett registrering (1-times frist for redigering)	Medlem+
PUT	/api/registrations/{id}	Oppdater registrering (innen 1 time etter opprettelse)	Billettansvarlig+
DELETE	/api/registrations/{id}	Slett registrering (innen 1 time etter opprettelse)	Billettansvarlig+
GET	/api/me/history	Hent brukerens salgshistorikk	Medlem+
GET	/api/me/stats	Hent brukerens statistikk	Medlem+

Admin / oversikt

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/management/dashboard/{eventId}	Hent oversiktsstatistikk	Billettansvarlig+
GET	/api/management/dashboard/{eventId}/export	Eksporter CSV	Billettansvarlig+
GET	/api/management/dashboard/{eventId}/export-excel	Eksporter Excel	Billettansvarlig+
PUT	/api/management/members/{userId}/invoice/{eventId}	Sett eller fjern fakturastatus for medlem og arrangement	Billettansvarlig+
PUT	/api/management/registrations/{id}/invoice	Marker én registrering som fakturert	Billettansvarlig+

Medlems- og arrangementsendepunktet aksepterer { "invoiced": true } for å registrere at fakturaen er utstedt eller sendt, og { "invoiced": false } for å fjerne denne statusen. Et tomt objekt støttes midlertidig som eldre veksleoppførsel, men førstepartsklienter sender uttrykkelig ønsket status. Den eldre retningen bygger bare på kvalifiserte poster: når alle kvalifiserte poster allerede er fakturert, fjernes statusen selv om uavklarte eller ugyldige trykte bestillinger fortsatt finnes.

Kvalifiserte poster er aktive direkteregistreringer og aktive avstemte bestillinger med gyldig, låst fakturagrunnlag eller et verifisert gjenopprettet grunnlag. Arkiverte avstemte bestillinger kan markeres som fakturert, men må gjenopprettes før fakturastatus fjernes. Uavklarte bestillinger og ugyldige grunnlag uten verifisert gjenoppretting endres ikke. Fakturabeløpet er summen av registreringenes totalAmount og det kontrollerte grunnlaget for trykte bestillinger. Det bruker aldri TicketOrder.totalAmount og overskriver ikke det opprinnelige låste grunnlaget.

Operasjonen bruker ETag-vilkår for hver post. Resultatet rapporterer samlede og typespesifikke tall for oppdatert, uendret, konflikt, uavklart, ugyldig og mislykket. Markøren completed er bare true når ingen konflikt eller skrivefeil oppstod. En forespørsel med konflikter eller skrivefeil returnerer HTTP 207 med completed: false og beholder vellykkede oppdateringer. Gjentakelse av samme uttrykkelige forespørsel konvergerer uten å veksle poster som allerede har riktig status.

Kontroll og bekreftelse av flere økonomiske poster

Tilgjengelig i v1.9.0

Disse fire POST-endepunktene implementerer #538 og #537. Eksisterende enkeltendepunkter for avstemming og fakturastatus er uendret.

Alle fire krever ?organizationId={organizationId} og eksisterende requireTicketManager-autorisasjon, inkludert autoriserte høyere roller. Serveren håndhever én organisasjon og ett eid arrangement. Delegerte visninger avvises. Kanonisk testdatamerking kontrolleres ved forhåndsvisning, ved starten av bekreftelsen og under behandlingen. Merkede arrangementer utelates. Ingen overstyring for å vise testdata innføres.

Vellykkede svar bruker { "success": true, "data": ... }, HTTP 200 og Cache-Control: no-store, også ved blandede resultater. HTTP-statusen betyr ikke at alle poster er fullført. Manglende organisasjon, ugyldige eller tomme utvalg, duplikate ID-er, uventede felt, ukjente handlinger og manglende revisjon ved bekreftelse gir valideringsfeil (400). Manglende arrangement eller feil organisasjon gir 404. Autorisasjon og rapportklassifisering beholder eksisterende feilsvar.

POST /api/orders/bulk-reconciliation/preview

{ "eventId": "event-id", "items": [{ "orderId": "order-id" }] }

data.items[] inneholder orderId, memberName, eligible og valgfrie showtimeLabel, revision, soldQuantity, returnedQuantity, amount, blocker. blocker er invalidBasis eller ineligible. amount er kontrollert fakturagrunnlag for solgte billetter, aldri bestillingstotalen. Returer bidrar ikke til beløpet. Manglende bestillinger eller bestillinger utenfor utvalget gir en rad som ikke kan behandles, uten bestillingens detaljer.

Kvalifiserte bestillinger venter på avstemming, er ikke arkivert eller slettet, er ikke allerede fakturert eller låst, har ETag og består eksisterende validering av fakturagrunnlaget. Forhåndsvisningen endrer ingenting.

POST /api/orders/bulk-reconciliation/confirm

{ "eventId": "event-id", "items": [{ "orderId": "order-id", "revision": "preview-revision" }] }

data.outcomes[] inneholder { orderId, outcome }. Resultatene er completed, alreadyCompleted, changed, ineligible eller failed.

Hver fullført bestilling får sitt eget låste grunnlag for solgte billetter gjennom eksisterende avstemmingshandling, med godkjenner, tidspunkt og varsel som før. En gyldig bestilling som allerede er avstemt, gir alreadyCompleted uten ny skriving eller nytt varsel. Endrede grunnlag eller skrivekonflikter krever ny kontroll. Låste eller fakturerte poster kan ikke avstemmes på nytt. Handlingen utsteder ikke fakturaer, endrer ikke faktura- eller betalingsstatus, slår ikke sammen bestillinger og avstemmer ingenting uten bekreftelse.

POST /api/management/member-invoices/preview

{ "eventId": "event-id", "members": [{ "userId": "member-id" }] }

Utvalget gjelder medlemmer på tvers av alle forestillinger i ett arrangement, ikke bestillings-ID-er eller én forestilling. data.items[] inneholder userId, memberName, revision, summary, pendingCount, pendingAmount og invalidRegistrationCount.

summary beholder feltene fra MemberInvoiceSummary: state, eligibleCount, invoicedCount, unresolvedOrderCount, invalidBasisOrderCount, recoveryRequiredOrderCount, recoveredOrderCount, invoiceAmount, allEligibleInvoiced. Antall gjelder kildeposter, ikke billetter eller fakturadokumenter. invoiceAmount er gyldig total inkludert allerede markerte poster. pendingAmount og pendingCount gjelder bare kvalifiserte poster som ikke er markert ennå.

Kvalifiserte kilder er aktive direkte salgsregistreringer med konsistente beløp kontrollert i hele øre, og avstemte bestillinger av trykte billetter med kontrollert grunnlag, inkludert verifisert gjenoppretting. Partnersalg, slettede, kansellerte, uavklarte og ugyldige kilder utelates der det er relevant. Arkiverte avstemte bestillinger kan fortsatt markeres som fakturert. Returer inngår aldri i beløpet for trykte billetter. Gjenoppretting overskriver ikke den opprinnelige låste dokumentasjonen. Advarsler beholdes. Kvalifiserte poster kan behandles selv om andre poster utelates. Dette betyr ikke at hele medlemmets fakturagrunnlag er klart.

POST /api/management/member-invoices/confirm

{ "eventId": "event-id", "members": [{ "userId": "member-id", "revision": "preview-revision" }] }

data.outcomes[] inneholder { userId, outcome, records: [{ id, kind, outcome }] }. Medlemsresultater er completed, alreadyCompleted, changed, ineligible, failed eller partial. kind er registration eller order. Kilderesultatene som returneres, er completed, alreadyCompleted, changed eller failed. Tidlige medlemsresultater kan ha tom records-liste.

Handlingen setter bare fakturamerking til sann. Den godtar ikke bestillingsutvalg, forestillingsavgrensning, flere arrangementer eller ønsket usann status. Grensesnittet krever uttrykkelig bekreftelse på at fakturaene for de viste kvalifiserte beløpene er utstedt eksternt. Avkrysningsboksen er en kontroll i grensesnittet, ikke et ekstra forespørselsfelt. Serveren registrerer aktør og tidspunkt per kilde med eksisterende korrigeringslåser og betingede skriveoperasjoner. Eksisterende merking beholdes. Handlingen oppretter eller sender aldri fakturaer, fjerner ikke merking, registrerer ikke betaling, avstemmer ikke bestillinger og slår ikke sammen poster.

Revisjoner, delvise resultater og nye forsøk

Revisjonene er SHA-256-verdier som klienten skal sende tilbake uendret. Bestillingsrevisjonen omfatter kildedokumentet og ETag. Medlemsrevisjonen omfatter alle innlastede kilder, ETag-er og advarsler, også uavklarte poster, ikke bare kvalifiserte beløp. Nye eller endrede kilder gjør den tidligere kontrollen utdatert, med mindre alle kvalifiserte poster allerede er markert og ingen skriving trengs.

Utvalget behandles ikke som én alt-eller-ingenting-transaksjon. partial beholder lagrede endringer. completed gjelder bare kvalifiserte kilder, ikke utelatte poster med advarsler. Fullført arbeid forblir fullført. Klientene prøver ikke automatisk på nytt. Oppdater og kontroller gjenstående eller endrede kilder før ny bekreftelse. Et usikkert nettverkssvar betyr ikke at ingenting ble lagret. Allerede fullført arbeid endres ikke ved gjentakelse, men en delvis oppdatering endrer medlemsrevisjonen og krever ny kontroll.

Kildenes ETag-er og korrigeringslåser beskytter hver endring. Kontroll av kanonisk testdatamerking er separat fra kildeskriving. Kontrakten lover ikke en transaksjon på tvers av containere mellom arrangementsmerking og økonomiske endringer.

Invitasjoner

Metode	Endepunkt	Beskrivelse	Autent.
POST	/api/organizations/{organizationId}/invitations	Opprett invitasjonskode	Admin
GET	/api/organizations/{organizationId}/invitations	List invitasjoner	Admin
DELETE	/api/organizations/{organizationId}/invitations/{code}	Slett eller tilbakekall invitasjon	Admin
GET	/api/join/{code}	Valider invitasjonskode	Offentlig
POST	/api/join/{code}	Godta invitasjon og bli med i organisasjon	Offentlig

Superadmin

Synlighet for utviklingsorganisasjoner

GET /api/organizations?view=workspace filtrerer bare organisasjonslisten i superadministratorens arbeidsområde. Vanlige organisasjoner og utviklingsorganisasjoner som er valgt for den innloggede brukeren, returneres. Filtreringen skjer før paginering. Vanlige medlemmer får fortsatt sine godkjente medlemskap. view=management krever superadmin-tilgang og viser alle organisasjoner som ikke er slettet, også skjulte utviklingsorganisasjoner. Uten view beholdes den eksisterende komplette superadmin-listen. Direkte tilgang til objekter endres ikke.

GET /api/shared-event-organizations/search?view=workspace bruker samme synlighetsregel før resultatgrensen, både ved opprettelse og ved søk for et eksisterende arrangement, for formålene sharedEvent og delegatedSales. Eksisterende begrensninger for kapabilitetsmodus gjelder fortsatt. Uten view beholdes eksisterende søkeatferd.

GET /api/organization-development-admins krever superadmin-tilgang og returnerer bare ID og visningsnavn for nåværende superadministratorer som kan velges.

PUT /api/organizations/{id}/development-visibility krever en nåværende superadministrator som handler direkte, uten representasjon. Send { "isDevelopment": true, "superAdminIds": ["user-id"], "expectedRevision": 0 }. Listen kan inneholde opptil 100 unike ID-er for eksisterende superadministratorer. Tomme valg er tillatt og kan endres via administrasjonsvisningen. Send isDevelopment: false og en tom liste for vanlig synlighet. Manglende metadata betyr revisjon null; hver godkjent endring øker revisjonen. En utdatert eller gjentatt revisjon gir 409 og krever ny innlasting.

Det eksisterende organisasjonsdokumentet lagrer valgfri developmentVisibility med isDevelopment, superAdminIds, revision, updatedAt og updatedBy. Endringene bruker eksisterende ETag-sikker lagring og bevarer andre felt. Vanlig opprettelse og oppdatering av organisasjoner avviser dette feltet. Ingen ny beholder, rolle, medlemskap, rapportutelatelse eller endring av økonomiske data innføres. Slettede brukere og endrede roller kan etterlate utdaterte valg. Alle superadministratorer kan finne organisasjonen via administrasjonsvisningen og erstatte disse valgene.

Endepunkter

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/organizations	List alle organisasjoner	Superadmin
GET	/api/organization-development-admins	List ID-er og navn for synlighetsvalg	Superadmin
PUT	/api/organizations/{id}/development-visibility	Endre synlighet for utviklingsorganisasjon med forventet revisjon	Superadmin, uten representasjon
POST	/api/organizations	Opprett organisasjon	Superadmin
GET	/api/organizations/{id}	Hent organisasjonsdetaljer	Superadmin
PUT	/api/organizations/{id}	Oppdater organisasjon	Superadmin
PUT	/api/organizations/{id}/mode	Endre organisasjonens kapabilitetsmodus	Superadmin
GET	/api/organizations/{id}/owner-state-coordination	Les koordinering for modusoverganger og låser for eiertilstand	Superadmin
POST	/api/organizations/{id}/owner-state-coordination/recover	Fjern én nøyaktig foreldet koordineringsoperasjon etter kontroll	Superadmin
DELETE	/api/organizations/{id}	Slett organisasjon	Superadmin
POST	/api/organizations/{id}/members/import	Importer medlemmer via CSV	Superadmin
GET	/api/organizations/{id}/members	List organisasjonsmedlemmer	Superadmin
POST	/api/organizations/{id}/members	Legg til medlem i organisasjon	Superadmin
PUT	/api/organizations/{id}/members/{memberId}	Oppdater medlemsrolle	Superadmin
DELETE	/api/organizations/{id}/members/{memberId}	Fjern medlem fra organisasjon	Superadmin
GET	/api/users	List alle brukere	Superadmin
GET	/api/users/{id}	Hent brukerdetaljer	Superadmin
PUT	/api/users/{id}	Oppdater bruker	Superadmin
PUT	/api/users/{id}/super-admin	Slå av eller på superadmin-status	Superadmin
POST	/api/users/import	Importer brukere via CSV	Superadmin
DELETE	/api/users/bulk-delete	Masseslett brukere	Superadmin
POST	/api/users/bulk-assign-organization	Massetildel brukere til organisasjon	Superadmin
POST	/api/impersonation/audit	Logg representasjonshendelse	Superadmin
GET	/api/impersonation/audit	Hent representasjonslogger	Superadmin

Organisasjonens kapabilitetsmodus

En eksisterende organisasjon har én av to moduser:

• full — hele produktet. Fravær av feltet betyr full, og full lagres fortsatt som et fraværende felt.
• sellingPartner — begrenset modus for organisasjoner som beholder medlemmer, roller, innstillinger, varsler, delegerte invitasjoner, medlemsbestilling, godkjenning og levering, returer og partneravgrenset salg uten å eie arrangementer eller delta i delte arrangementer.

Bare plattformens superadmin kan angi modus ved oppretting eller gjennom PUT /api/organizations/{id}/mode. Vanlige organisasjonsadministratorer kan ikke skrive organizationMode gjennom det generelle oppdateringsendepunktet.

sellingPartner → full er alltid tillatt. full → sellingPartner lykkes bare når autoritative sjekker finner:

• Ingen eide arrangementer, inkludert mykt slettede arrangementer
• Ingen deltakelse i delte arrangementer
• Ingen inviterte eller aktive utgående salgspartnerdelegeringer

Avhengigheter gir 409 ORG_MODE_DOWNGRADE_BLOCKED. En uklar avhengighetssjekk gir 503 ORG_MODE_DEPENDENCY_CHECK_FAILED. En samtidig modusendring gir 409 ORG_MODE_TRANSITION_RACED. Ingen av tilfellene endrer modusen.

Nedgraderingen bruker en overgangsmarkør, korte låser for oppretting av eiertilstand, autoritative nye lesinger og ETag-betingelser. Dette koordinerer eksisterende dokumenter, men gir ikke transaksjonsatomisitet på tvers av containere.

GET /api/organizations/{id}/owner-state-coordination returnerer gjeldende modus, ETag og aktive operasjoner med type, ID, start, utløp og stale.

POST /api/organizations/{id}/owner-state-coordination/recover krever:

{
  "operationKind": "modeTransition",
  "operationId": "operation-id",
  "etag": "\"0000...\"",
  "reason": "Kontrollert forlatt operasjon"
}

Serveren fjerner bare akkurat denne operasjonen når type og ID fortsatt matcher, femminuttersvinduet er utløpt, ETag-en fortsatt matcher og begrunnelsen er 3–1 000 tegn. Endret, manglende eller ikke-foreldet operasjon gir 409 ORG_OWNER_STATE_RECOVERY_CONFLICT. Gjenoppretting endrer ikke modusen og hopper ikke over nedgraderingskontrollene. Operatøren må kjøre modusendringen på nytt. Personvernrenset telemetri registrerer resultatet.

Varsler

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/notifications	List gjeldende brukers varsler	Medlem+
POST	/api/notifications/{id}/read	Marker ett varsel som lest	Medlem+
POST	/api/notifications/read-all	Marker alle varsler som lest	Medlem+
DELETE	/api/notifications/{id}	Slett et varsel	Medlem+

Alle varselendepunkter krever ?organizationId={organizationId}. Varsler er avgrenset til innlogget bruker — du kan bare lese og slette dine egne varsler. Endepunktet returnerer de 50 nyeste varslene sortert etter createdAt DESC.

Når en vanlig eller delegert medlemsbestilling avslås, initierer API best-effort opprettelse av varsel i appen for bestillingseieren. Varselopprettelsen er deterministisk og bruker en stabil identitetsnøkkel for duplikatundertrykkelse, men kan ikke skrives hvis alle avgrensede forbigående forsøk uttømmes. Et mislykket varsel reverserer ikke bestillingsavslaget. For en delegert bestilling brukes soldByOrganizationId som varselpartisjon. Varselet inneholder arrangementsnavn og lenke til historikken, men utelater den ansattes avslagsgrunn, notater og interne identifikatorer. Varselresponsen bruker Cache-Control: no-store.

Rapporter

Metode	Endepunkt	Beskrivelse	Autent.
GET	/api/management/reports	Hent rapportdata (alle faner)	Kasserer+
GET	/api/management/reports/export	Eksporter rapport som CSV	Kasserer+

Queryparametere for GET /api/management/reports:

Parameter	Verdier	Beskrivelse
type	members, choirs, events, types, ticketmaster, all	Rapportfane som skal lastes
organizationId	organisasjons-ID	Påkrevd
eventId	arrangements-ID	Valgfritt filter

Finansiell rapportering for trykte bestillinger omfatter bare faktisk salg. Ventende og godkjente bestillinger bidrar med null. Leverte bestillinger og bestillinger som venter på avstemming bruker validerte rapporterte salgslinjer når de finnes; oppgjorte bestillinger bruker det validerte låste fakturagrunnlaget. Returnerte eller utestående billetter bidrar ikke med inntekt eller gebyr, og ugyldige eller ufullstendige detaljer faller aldri tilbake til TicketOrder.totalAmount.

Queryparametere for eksport:

Parameter	Verdier	Beskrivelse
exportType	transactions, members, showtimes, orders, ticketmaster	Hva som skal eksporteres. Ticketmaster-eksporten lager én rad per kjent kategorilinje og beholder original etikett, antall, kobling, kapasitetsvalg, brutto og tilgjengelig pris-/gebyrfordeling
format	csv	Filformat (bare CSV foreløpig)
organizationId	organisasjons-ID	Påkrevd
locale	en eller no	Sendes uttrykkelig fra aktiv klient for exportType=ticketmaster; andre verdier avvises. Eldre kall uten parameter beholder norsk standard.

CSV-eksportene transactions, members og showtimes bruker de samme solgte antallene, prisene fra bestillingstidspunktet og gebyrantallene som rapportresponsen. Ticketmaster-CSV bruker valgt språk for kolonneoverskrifter, datoer, kapasitetsverdier og meldinger om utilgjengelig/justert fordeling. Korreksjoner uten linjefordeling får én tydelig «fordeling ikke tilgjengelig»-rad i stedet for gamle kategoriantall.

Administrasjon

Metode	Endepunkt	Beskrivelse	Autent.
POST	/api/management/cleanup	Slett alle data (bare dev/test)	Superadmin
GET	/api/management/events/{eventId}/external-sales	List eksternt salg for arrangement	Billettansvarlig+
GET	/api/management/events/{eventId}/showtimes/{showtimeId}/external-sales	List eksternt salg per forestilling	Billettansvarlig+
POST	/api/management/events/{eventId}/ticketmaster-categories	Opprett gjenbrukbar Ticketmaster-kategori	Billettansvarlig+
PUT	/api/management/events/{eventId}/ticketmaster-categories/{categoryId}	Rediger gjenbrukbar Ticketmaster-kategori	Billettansvarlig+
DELETE	/api/management/events/{eventId}/ticketmaster-categories/{categoryId}?version={version}	Slett gjenbrukbar Ticketmaster-kategorirevisjon	Billettansvarlig+
POST	/api/management/events/{eventId}/showtimes/{showtimeId}/external-sales	Opprett ekstern salgsoppføring	Billettansvarlig+
PUT	/api/management/external-sales/{id}	Oppdater eksternt salg	Billettansvarlig+
DELETE	/api/management/external-sales/{id}	Slett eksternt salg	Billettansvarlig+

Administrasjonsopprydding

Endepunktet POST /api/management/cleanup er bare tilgjengelig når E2E_TEST_MODE=true og krever superadmin-autentisering. Send ?confirm=yes for å faktisk slette alle data. Advarsel: Dette sletter ALLE organisasjoner, arrangementer, registreringer, billetttyper og andre applikasjonsdata. Bruk det bare i utviklings- og testmiljøer.

---

Neste: Miljøvariabler · Se også: Arkitektur · Datamodell