Αναφορά API / Αυθεντικοποίηση
Τα bearer tokens, αναλυτικά
Κάθε αίτημα στο API του HyperCRM φέρει μία κεφαλίδα: `Authorization: Bearer <token>`. Αυτή η σελίδα καλύπτει ακριβώς τι μπορεί να είναι αυτό το token, πώς απορρίπτεται μια κακοσχηματισμένη ή άκυρη κεφαλίδα, και τον συγκεκριμένο κωδικό σφάλματος για κάθε περίπτωση αποτυχίας.
Η κεφαλίδα
Κάθε endpoint απαιτεί Authorization: Bearer <token>. Υπάρχουν δύο έγκυρα είδη token: ένα Firebase ID token από μια συνδεδεμένη συνεδρία HyperCRM, ή ένα αδιαφανές OAuth access token (hcrm_at_...) που εκδίδεται από τον δικό του διακομιστή εξουσιοδότησης OAuth 2.1 του HyperCRM για το endpoint MCP. Και τα δύο γίνονται δεκτά όπου αναμένεται bearer token — ο διακομιστής ελέγχει αν το token ξεκινά με hcrm_at_ και, αν όχι, καταφεύγει σε επαλήθευση Firebase ID token.
Χωρίς ξεχωριστό βήμα εγγραφής
Δεν υπάρχει πίνακας API-key ούτε endpoint εγγραφής για έναν καλούντα αυθεντικοποιημένο με Firebase. Στην πρώτη επιτυχή επαλήθευση μιας δεδομένης ταυτότητας Firebase, το HyperCRM βρίσκει ή δημιουργεί τον αντίστοιχο χρήστη, ιατρείο, και γραμμή ιδιοκτήτη-μέλους. Κάθε επόμενη κλήση επιλύει το ίδιο ιατρείο από το token — ένα αίτημα ποτέ δεν προμηθεύει το δικό του practiceId.
OAuth access tokens
Για πελάτες MCP, το HyperCRM εκδίδει τα δικά του αδιαφανή access tokens hcrm_at_... και refresh tokens hcrm_rt_... μέσω μιας συμβατής με πρότυπα ροής OAuth 2.1: δυναμική εγγραφή πελάτη, μια οθόνη συναίνεσης βασισμένη στην ίδια σύνδεση Firebase, και υποχρεωτική ανταλλαγή κωδικού εξουσιοδότησης PKCE (S256). Τα tokens δεν είναι ποτέ JWT — αποθηκεύεται μόνο το SHA-256 hash τους — και ένα refresh token περιστρέφεται σε κάθε χρήση, ακυρώνοντας το προηγούμενο.
Όταν αποτυγχάνει η αυθεντικοποίηση
Μια απούσα κεφαλίδα επιστρέφει missing_authorization· μια κεφαλίδα που δεν είναι Bearer <token> επιστρέφει invalid_authorization_header· ένα μη αναλύσιμο ή μη επαληθεύσιμο token επιστρέφει invalid_auth_token ή auth_token_verification_failed. Ένα ληγμένο token επιστρέφει expired_auth_token, και ένα ανακληθέν επιστρέφει revoked_auth_token — και τα τέσσερα είναι HTTP 401. Ένας απενεργοποιημένος λογαριασμός είναι HTTP 403, όχι 401: το ίδιο το token εξακολουθεί να επαληθεύεται σωστά, αλλά η ταυτότητα πίσω του είναι απενεργοποιημένη, εμφανιζόμενη ως disabled_auth_token ή user_disabled ανάλογα με ποια πλευρά το σημείωσε. Τα unsupported_auth_provider και auth_provider_email_required (και τα δύο 403) καλύπτουν παρόχους σύνδεσης που το HyperCRM δεν υποστηρίζει για πρόσβαση API. Το auth_configuration_missing (503) σημαίνει ότι ο ίδιος ο διακομιστής δεν έχει ρυθμισμένο έργο Firebase.
Δείτε την πλήρη αναφορά σφαλμάτων για το πώς αυτοί οι κωδικοί εντάσσονται στον γενικό φάκελο σφάλματος, και τον κόμβο αναφοράς API για τις υπόλοιπες σελίδες πόρων.
Συχνές ερωτήσεις
Τα αρχεία ασθενών κρυπτογραφούνται κατά τη μεταφορά και την αποθήκευση, τα αρχεία φυλάσσονται ιδιωτικά και σερβίρονται μέσω συνδέσμων περιορισμένης διάρκειας, ενώ κάθε αλλαγή καταγράφεται. Το προσωπικό συνδέεται με passkeys αντί για κοινούς κωδικούς.
Ναι, χρησιμοποιώντας αντ' αυτού ένα OAuth access token. Το HyperCRM τρέχει τον δικό του διακομιστή εξουσιοδότησης OAuth 2.1 για πελάτες MCP: ένας πελάτης εγγράφεται μόνος του, ένας χρήστης εγκρίνει πρόσβαση μέσω οθόνης συναίνεσης βασισμένης στην κανονική σύνδεση Firebase, και ο πελάτης λαμβάνει ένα αδιαφανές access token για χρήση ως bearer token.
Επειδή το ίδιο το token εξακολουθεί να είναι έγκυρο και επαληθεύεται σωστά — ο λογαριασμός πίσω του είναι απενεργοποιημένος, κάτι διαφορετικό από ένα άκυρο ή ληγμένο διαπιστευτήριο. Το HyperCRM το αντιμετωπίζει ως πρόβλημα εξουσιοδότησης (403) αντί για πρόβλημα αυθεντικοποίησης (401), και το τεκμηριώνει ως σκόπιμη εξαίρεση.
Ναι. Τα OAuth access tokens έχουν μικρή διάρκεια ζωής, και ένα refresh token μπορεί να ανταλλαγεί για νέο ζεύγος access/refresh χωρίς ο χρήστης να εγκρίνει ξανά συναίνεση. Τα refresh tokens περιστρέφονται σε κάθε χρήση, οπότε το προηγούμενο σταματά να λειτουργεί τη στιγμή που εκδίδεται νέο ζεύγος, περιορίζοντας τη ζημιά ενός διαρρεύσαντος token.