Historia zmian i wersjonowanie

#Wersjonowanie

Wersja jest częścią adresu: /api/v1. Przepływ lub integracja zbudowane na v1 nie wymagają przebudowy, gdy AttendBeacon się zmienia, dlatego w ramach v1:

• Dodajemy, nigdy nie zabieramy. Nowe operacje, nowe pola w odpowiedziach, nowe opcjonalne parametry, nowe wartości list, takie jak rodzaj webhooka czy kod błędu. Pisz kod, który ignoruje to, czego nie zna.
• Nigdy nie zmieniamy nazwy ani nie usuwamy raz wprowadzonego pola, operacji, uprawnienia, kodu błędu ani rodzaju webhooka.
• Zmiana, która coś psuje, to v2. Ogłaszamy ją tutaj oraz e-mailem do każdej przestrzeni roboczej, która ma klucz, co najmniej sześć miesięcy przed zmianą v1, a v1 działa dalej przez te sześć miesięcy.
• To, co jest wycofywane, oznaczamy jako deprecated w opisie OpenAPI i wymieniamy tutaj wraz z datą usunięcia.

Zmianami w tym sensie nie są: kolejność pól w treści, tekst detail (rozgałęziaj według code), nowe nagłówki odpowiedzi ani poprawienie odpowiedzi, która była sprzeczna z tą dokumentacją.

Opis OpenAPI 3.1 pod adresem /api/v1/openapi.json przedstawia API w obecnej postaci. info.version zmienia się przy każdym dodaniu.

#2026-10-15: v1.1, platforma dla programistów

• Uprawnienia według obszarów. Uprawnienia klucza to teraz obszar i rodzaj dostępu (events:read, attendees:write), a dane osobowe mają własne uprawnienie, people:read. Wcześniej utworzone klucze mogą dokładnie to samo co przedtem.
• Klucze wygasają i są rejestrowane. Klucz może wygasnąć po 30, 90, 180 lub 365 dniach. Każde wywołanie trafia do Aktywności kluczy, łącznie z odmowami.
• Problem details. Odmowy mają format RFC 9457 application/problem+json ze stałym code. error pozostaje obok detail dla wcześniej zbudowanych przepływów.
• Kursory i synchronizacja. Każda lista zwraca nextCursor i hasMore, a listy elementów, które się zmieniają, przyjmują updatedSince. page i pageSize nadal działają tam, gdzie działały.
• Bezpieczne ponowienia i zmiany. Idempotency-Key przy każdym POST; ETag przy pojedynczych zasobach, If-None-Match i If-Match.
• Nagłówki limitów wywołań. RateLimit, RateLimit-Policy i X-RateLimit-* w każdej odpowiedzi, Retry-After przy 429.
• Nowe operacje: przestrzeń robocza; tworzenie wydarzeń jako szkiców, zmiana ich podstawowych danych i publikacja; statystyki wydarzenia i tempo sprzedaży; rodzaje biletów (i ich zmiana), dodatki i kody rabatowe (i ich tworzenie); zamówienie; wyszukiwanie uczestników; liczniki wejść; sesje (oraz ich dodawanie i zmiana), sale, ścieżki i prelegenci; sponsorzy i poziomy sponsorskie; zgłoszenia do naboru prelegentów; ekipa i zmiany; ankiety, ich wyniki i oceny sesji; faktury i faktury korygujące; podsumowanie budżetu; ranking zestawu do udostępniania; społeczności i ich członkowie; punkty końcowe webhooków, ich dostarczenia, testy i sekrety oraz rodzaje zdarzeń ze schematami ich treści.
• Moduły. Wyłączony moduł wydarzenia zwraca 409 moduleOff na swoich punktach końcowych. Dotyczy to także wejść, skanów przy wejściu i check-inu (moduł check-in) oraz leadów (moduł leadów), które wcześniej odpowiadały.
• Osoby. Bez people:read uczestnicy, kupujący, ekipa i członkowie są tylko identyfikatorami. Leady i wyszukiwanie uczestników wymagają tego uprawnienia. Osoba, która usunęła swoje dane, ma status erased, bez żadnych danych osobowych.
• Opisy. /api/v1/openapi.json to teraz OpenAPI 3.1, z przykładami i wszystkimi odmowami. Opis Swagger 2.0 importowany przez Power Platform jest pod adresem /api/v1/swagger.json.
• Serwer MCP pod adresem /mcp, dla asystentów AI.

#2026-10-12: v1.0

• Wydarzenia, uczestnicy z odpowiedziami, zamówienia i skany przy wejściu w przestrzeni roboczej, z updatedSince.
• Rejestracja osoby z bezpłatnym biletem, anulowanie biletu i check-in osoby.
• Subskrypcje dla Power Automate, Zapier i Make (/hooks) oraz webhooki podpisane zgodnie ze Standard Webhooks.
• Pytania rejestracyjne, ich schemat JSON, rodzaje biletów, wejścia i ostatnie leady – do list wyboru i pól w przepływach.