Lookups

Die go~mus-API bietet mehrere Lookup-Endpoints mit Stammdaten-Konstanten - Länder, Bundesländer, Versandarten, Anreden, Titel. Die IDs aus diesen Listen tauchen als Werte in vielen anderen Endpoints wieder auf (Customer-Adressen, Order-Items, Filter-Parameter). Diese Seite sammelt sie an einem Ort.

Vollständige Endpoint- und Schema-Referenz: Swagger.

Endpoints im Überblick

Endpoint	Wofür	Wo du die IDs brauchen
`GET /api/v4/countries`	Liste aller Länder mit ISO-Code	`addr_country_id` bei Customers/Orders
`GET /api/v4/states`	Bundesländer/Regionen mit Land-Bezug	Adressformulare, Reporting
`GET /api/v4/dispatch_modes`	Versandarten der Instanz	`dispatch_mode_id` bei Annual Tickets, Orders mit Versand
`GET /api/v4/customers/salutations`	Anreden	`customer_salutation_id` bei Customer-Create
`GET /api/v4/customers/titles`	Akademische Titel	`customer_title_id` bei Customer-Create
`GET /api/v4/events/categories`, `audiences`, `languages`	Event-Filter-Konstanten	Event-Listen-Filter
`GET /api/v4/tours/categories`, `audiences`, `languages`	Tour-Filter-Konstanten	Tour-Listen-Filter

Beispiel-Responses

Countries

curl "https://demo.gomus.de/api/v4/countries"

{
  "countries": [
    { "id": 60, "name": "Deutschland", "code": "DE" },
    { "id": 76, "name": "Frankreich", "code": "FR" }
  ],
  "meta": { "total_count": 249, "page": 1, "per_page": 25 }
}

code ist ISO-3166-1-Alpha-2. Damit lässt sich der Server-country_id clientseitig mit gängigen Bibliotheken matchen, ohne erst den Lookup-Call abzuwarten.

States

curl "https://demo.gomus.de/api/v4/states"

{
  "states": [
    { "id": 3, "name": "Berlin", "country_id": 60 },
    { "id": 1, "name": "Baden-Württemberg", "country_id": 60 }
  ],
  "meta": { "total_count": 16, "page": 1, "per_page": 25 }
}

Dispatch Modes

curl "https://demo.gomus.de/api/v4/dispatch_modes"

Antwort variiert je Instanz - z.B. E-Mail, Post, Abholung im Museum, Servicegebühr. Niemals hart kodieren.

Salutations und Titles

curl "https://demo.gomus.de/api/v4/customers/salutations"
curl "https://demo.gomus.de/api/v4/customers/titles"

Salutations sind instanz-spezifisch. Manche Häuser pflegen eigene Anreden ("Familie", "Firma") zusätzlich zu den Standards. Titel ebenso (z.B. "Prof. Dr. Dr.").

Caching-Hinweis

Lookups ändern sich praktisch nie. Cache-Strategie: einmal pro Tag lokal aktualisieren, im Frontend nur die gecachte Liste verwenden. So vermeidest du unnötige Roundtrips beim Rendern jedes Formulars.

Bei Setup-Zeit empfiehlt sich, die Listen einmal frisch zu holen und ins eigene Schema zu übersetzen - die go~mus-IDs sind instanz-spezifisch, und ein Backup der Mapping-Tabelle erleichtert spätere Audits.

Stolperdrahte

IDs sind instanz-spezifisch. Das Land "Deutschland" hat auf einer Instanz die ID 60, auf einer anderen vielleicht 1. Die ISO-Codes (code: "DE") sind stabil; nutzt du die als Bridge, falls du zwischst Instances syncen.
Pagination kann zubeißen. countries hat ~249 Einträge, der Default-per_page aber 25. Beim ersten Sync per_page=300 setzen oder über alle Seiten iterieren.
Salutations/Titles vor dem Customer-Create holen. Wenn du eine Salutation-ID raten, scheitert der Create mit Validierungs-Fehler.