Tipi di connessione

Ogni connessione riporta un provider, che assume uno di due valori:

Entrambi i tipi inviano e ricevono tramite gli stessi endpoint, con gli stessi corpi delle richieste e gli stessi due id di messaggio. Se pensava che collegare un QR dalla propria app fosse impossibile: non lo è.

In cosa differiscono davvero

Webhooks. Gli eventi vengono inviati solo per le connessioni qr. Le connessioni cloud_api oggi non emettono alcun webhook: per queste interroghi GET /messages e GET /connections/{id}.

Associazione. POST /connections/{id}/pairing-code è un concetto proprio di qr. Un numero cloud_api risponde 409 not_supported_for_provider; è un rifiuto permanente, quindi non lo ripeta.

Latenza di invio. Un invio qr richiede normalmente 1–7 s (fino a ~20 s per un testo lungo) e può richiedere ~2,5 minuti nel percorso di auto-ripristino. Un invio cloud_api richiede circa 1 s. Dimensioni il timeout HTTP sul caso più lento: almeno 180 s.

Segnare come letto. POST /messages/read segna come letta l'intera chat su una connessione qr. Una connessione cloud_api può segnare solo un messaggio specifico, quindi una richiesta con il solo phone individua automaticamente il messaggio in entrata più recente di quel numero.

Volume. Un numero qr appena associato ha limiti di riscaldamento di 72 ore sul volume orario; superarne uno restituisce 429 warmup_limited. Vedere Licenze e prova.

Salute della sessione. Una connessione qr è legata a un telefono che deve restare raggiungibile, quindi può cadere e richiedere una nuova associazione: è a questo che servono connection.disconnected / connection.connected e il flag needs_reconnect. Una connessione cloud_api non scansiona mai nulla e non presenta questo tipo di guasto.