Correzione automatica dei ticket tramite webhook
Collega i sistemi di ticketing on-prem o non supportati a Devin con un bridge da webhook a sessione.Crea un utente di servizio
Devin utilizza i service user tokens per autenticare le chiamate API. Questo è l’approccio consigliato per l’automazione in ambiente di produzione.Riceverai un
- Vai su app.devin.ai > Settings > Service Users e crea un nuovo service user con l’autorizzazione
ManageOrgSessions - Copia il token API mostrato dopo la creazione e conservalo in modo sicuro — viene visualizzato solo una volta e lo utilizzerai come
DEVIN_API_KEYnell’handler del tuo webhook
GET https://api.devin.ai/v3/enterprise/organizations con il tuo token — l’URL mostra solo lo slug dell’organizzazione, non l’ID.Esegui un rapido test con curl:session_id e un url. Elimina la sessione di test nella web app di Devin e continua.Implementa il gestore del webhook
Questo pattern è ideale per sistemi di ticketing on-prem (come Jira self-hosted, Redmine o Bugzilla) o strumenti di ticketing che non hanno un’integrazione nativa con Devin (a differenza di Linear e Jira Cloud, che offrono supporto integrato). Se il tuo sistema di ticketing supporta i webhook, puoi collegarlo a Devin con un piccolo servizio.Includi nel prompt un link alla documentazione dell’API del tuo sistema di ticketing, così Devin può capire come inviare commenti ai ticket. Passa il token dell’API di ticketing come session secret in modo che Devin possa autenticarsi direttamente.Chiedi a Devin di creare lo scheletro del servizio:Ecco come si presenta l’handler principale:La mappa
PLAYBOOKS associa le etichette dei ticket ai playbook che crei in Settings > Playbooks. Un playbook per la correzione di bug potrebbe dire “Aggiungi sempre un test di regressione”; un playbook per le feature potrebbe dire “Crea una PR in bozza e richiedi una revisione.”Il prompt include un link alla documentazione API del tuo sistema di ticketing, così Devin sa come pubblicare i commenti in risposta. Il TICKET_API_TOKEN viene passato come session secret — viene iniettato come variabile d’ambiente solo per quella sessione e non viene mai archiviato. Sostituisci l’URL della documentazione API con la documentazione effettiva del tuo sistema di ticketing.Distribuisci l’handler in qualsiasi ambiente che possa ricevere richieste HTTPS POST — una funzione cloud (AWS Lambda, Google Cloud Functions), un container o un VPS. Registra il suo URL come webhook nelle impostazioni di notifica o integrazione del tuo sistema di ticketing e filtra per gli eventi ticket created.Crea un ticket di test con l’etichetta devin-autofix per verificare l’intero ciclo: ticket creato → webhook attivato → sessione Devin avviata → PR aperta → Devin pubblica un commento sul ticket.