FileMaker Data API: jak bezpiecznie połączyć CRM z aplikacją internetową

Przykładowy proces to formularz zapytania na stronie, który tworzy zgłoszenie w CRM FileMaker. Przeglądarka wysyła dane do backendu strony. Backend weryfikuje pola, ogranicza liczbę żądań i dopiero wtedy kontaktuje się z FileMaker. Hasła oraz token sesji integracji nie trafiają do publicznego kodu JavaScript.

Zaprojektuj stabilny kontrakt: identyfikator zgłoszenia, wymagane pola, dozwolone wartości i odpowiedź dla użytkownika. Przygotuj osobny układ API z potrzebnymi polami. Układ porządkuje wymianę danych, natomiast uprawnienia muszą ograniczać także dostęp do rekordów i pól.

Konto używane przez integrację powinno mieć własny zestaw uprawnień. Dla formularza tworzącego zgłoszenia nie przyznawaj automatycznie prawa odczytu wszystkich klientów ani usuwania rekordów. Włącz rozszerzone uprawnienie fmrest tylko w zestawach kont, które mają korzystać z Data API.

Sprawdź konfigurację usługi Data API na hoście oraz poprawny certyfikat HTTPS. Uwierzytelnianie zależy od hosta i rodzaju konta. Opisany dalej schemat logowania dotyczy konta pliku na FileMaker Server; dla kont Claris ID w FileMaker Cloud należy zastosować odpowiednią procedurę uwierzytelniania.

Backend wysyła POST do endpointu sessions dla wybranej bazy. Przy uwierzytelnianiu kontem pliku przekazuje Basic Authorization przez HTTPS oraz pusty obiekt JSON. Poprawna odpowiedź zawiera token, który identyfikuje sesję. Kolejne operacje używają nagłówka Authorization: Bearer z tym tokenem.

Nazwę bazy i układu koduj jako segmenty URL. Wersję API dobierz do używanego hosta i zweryfikuj kontrakt przed aktualizacją. Token przechowuj tylko tak długo, jak wymaga integracja, nie zapisuj go w logach i obsłuż wygaśnięcie sesji. Zamykaj sesje, których usługa już nie potrzebuje.

Rekord powstaje po wysłaniu POST do endpointu records wskazującego bazę i układ. Obiekt fieldData zawiera nazwy pól z układu oraz wartości. Przykład przedstawia treść żądania dla układu API_Zgloszenia, w którym istnieją pola ExternalId, Email i Topic. Wartość ExternalId generuje backend dla konkretnego zgłoszenia.

Pozostaw włączoną walidację pól i sprawdź jej działanie na błędnych danych. Uzgodnij reprezentację dat, liczb oraz pustych wartości. Po zapisie zachowaj powiązanie między identyfikatorem operacji po stronie aplikacji a recordId zwróconym przez FileMaker.

{
  "fieldData": {
    "ExternalId": "web-20260909-000123",
    "Email": "anna@example.com",
    "Topic": "Integracja katalogu produktowego"
  }
}

Sprawdzaj zarówno status HTTP, jak i tablicę messages w odpowiedzi JSON. Sam kod HTTP 200 nie wystarcza do oceny wyniku operacji; dokumentacja Claris wskazuje konieczność kontroli kodów błędów w messages. Oddziel błędne dane od braku uprawnień, wygaśniętej sesji i niedostępności hosta.

Po zerwaniu połączenia nie zakładaj, że zapis się nie odbył. Zaprojektuj obsługę stałego ExternalId, kontrolę unikalności i odczyt wyniku poprzedniej próby. Samo wyszukanie rekordu przed zapisem nie zabezpiecza dwóch równoległych żądań. Idempotencja, czyli powtarzanie bez powielania skutku, wymaga reguły po stronie zapisu.

• Przetestuj podwójne wysłanie tego samego zgłoszenia i dwie równoległe próby.
• Sprawdź niepoprawny e-mail, brak wymaganego pola i niedozwolony odczyt.
• Zasymuluj wygaśnięcie sesji i awarię po zapisaniu rekordu.
• Loguj identyfikator operacji oraz wynik, bez haseł i pełnej treści zgłoszenia.