Protocolli e compatibilità
Il gateway conserva i formati nativi delle superfici supportate. Ogni modello richiede un mapping verso un endpoint upstream compatibile; la piattaforma non aggiunge capacità assenti nel modello.
| Superficie | Endpoint | Utilizzo |
|---|---|---|
| Catalogo | GET /v1/models, GET /v1/models/{id} | Nomi pubblici consentiti alla chiave |
| Chat Completions | POST /v1/chat/completions | Conversazioni JSON o SSE, strumenti e output strutturato compatibili |
| Messages | POST /v1/messages | Protocollo Anthropic, tool use e thinking compatibili |
| Conteggio Messages | POST /v1/messages/count_tokens | Conteggio sul testo bonificato, senza addebito di inferenza |
| Responses | POST /v1/responses | Risposte e continuazioni con stato Netter previsto |
| Embeddings | POST /v1/embeddings | Testo singolo o batch con modello nominativo |
| System One | POST /v1/systemone | Decisioni strutturate Choice, Score e Noul |
| Files | /v1/files | Upload privati e gestione dei propri file |
| Audio | /v1/audio/* | Trascrizione, traduzione e sintesi quando configurate |
Nomi e capacità
I nomi pubblici possono includere namespace, per esempio vendor/model. Quando fanno parte del percorso URL, codificali correttamente. Un alias pubblico non è l’ID upstream: il client usa l’alias e il server risolve provider, protocollo e modello effettivo.
switchyard è un router per le superfici conversazionali supportate. Embeddings, audio e conteggio token usano mapping nominativi compatibili. Non usare modelli del catalogo di un altro provider senza che siano pubblicati da Netter.
Strumenti e funzioni escluse
Sono supportati gli strumenti eseguiti dal client e i formati nativi compatibili. Realtime, Batch, fine-tuning e strumenti cloud eseguiti dal provider non fanno parte di questa versione del gateway.
Per i client che abilitano funzioni proprietarie automaticamente, configura le opzioni ammesse e prova il flusso effettivo prima del rollout. La compatibilità di una richiesta testuale non dimostra quella di immagini, tool o ragionamento firmato.
Embeddings e System One
Con PII attivo, gli embeddings richiedono testo, non token ID precalcolati. La pseudonimizzazione usa il namespace previsto per il tenant: mantieni coerenza tra indicizzazione e query. Un cambio di modello può richiedere reindicizzazione.
System One riceve stato e domande strutturate secondo il proprio contratto e usa lo stesso plafond e gli stessi confini di autorizzazione. Il relativo mapping è indipendente dalle route di chat.
Per parametri e schemi consulta il contratto OpenAPI. Per lo stato applicativo vedi Responses.