Gli endpoint pronti per la produzione sono progettati per il 99,99% di uptime e gestione degli stati documentata.
Utilizzato da persone di aziende straordinarie
Segnali di fiducia prima dell’integrazione
Documentazione trasparente, richieste autenticate e dettagli di affidabilità visibili rendono più semplice valutare DomScan prima del rilascio.
OpenAPI, Swagger, Postman, CLI, SDK e link MCP sono a un clic.
Gli endpoint autenticati usano chiavi API con costi in crediti chiari prima della chiamata.
Inizia con 10.000 crediti mensili e fai upgrade solo quando l’uso cresce.
Cosa ti aiuta a costruire questa API
Usa questa pagina come brief di produzione: endpoint, esempi, forma della risposta e parti del workflow per integrare DomScan nel tuo prodotto.
Integra controlli dominio, intelligence DNS, segnali di rischio o arricchimento in onboarding, ricerca e strumenti interni.
Sostituisci lookup manuali ripetuti con job pianificati, alert e passaggi di indagine riproducibili.
Usa campi prevedibili, codici di stato documentati e costi in crediti invece di fare scraping di pagine provider.
Alimenta agenti, dashboard, playbook SOAR e CRM tramite OpenAPI, SDK, Postman o MCP.
Workflow di integrazione
Un percorso semplice dalla prima richiesta all’uso ripetibile in produzione.
Invia la tua chiave API con l’header documentato e mantieni richieste coerenti tra servizi.
Parti dagli esempi curl e HTTP, poi mappa i parametri nel codice della tua applicazione.
Usa codici di stato, costi in crediti e campi di risposta per costruire retry, log e alert.
Kit sviluppatori
Passa da questa pagina a docs leggibili da macchina, raccolte di richieste, SDK o strumenti per agenti.
Genera client o ispeziona ogni forma di richiesta e risposta.
Collezione PostmanImporta richieste pronte per test manuali e handoff al team.
SDK e CLIUsa pacchetti mantenuti e workflow da riga di comando invece di scrivere boilerplate.
Integrazione MCPEsponi intelligence sui domini ad agenti AI e assistenti interni.
Mappa di parametri e risposta
Controlla input, campi di output e codici di stato prima di collegare l’endpoint al tuo client.
Parametro
Risposta di esempio
Codici di stato HTTP
Endpoint
/v1/subdomains
Segnali di fiducia prima dell’integrazione
Documentazione trasparente, richieste autenticate e dettagli di affidabilità visibili rendono più semplice valutare DomScan prima del rilascio.
OpenAPI, Swagger, Postman, CLI, SDK e link MCP sono a un clic.
Gli endpoint autenticati usano chiavi API con costi in crediti chiari prima della chiamata.
Inizia con 10.000 crediti mensili e fai upgrade solo quando l’uso cresce.
Parti dagli esempi curl e HTTP, poi mappa i parametri nel codice della tua applicazione.
Caratteristiche Principali
Trova sottodomini dai log di Certificate Transparency.
Usa prefer_cache=1 per evitare di restare in attesa dei log CT; i mancati risultati a freddo restituiscono 202 e accodano un aggiornamento.
Scoperta non intrusiva senza toccare i server target.
Trova sottodomini dimenticati o shadow IT.
Mappa la superficie di attacco per i test di penetrazione.
Scopri i sottodomini dai record dei certificati storici.
I risultati in cache tornano subito; i mancati risultati cache-only includono indicazioni Retry-After.
Facile da integrare nei flussi di lavoro di sicurezza e negli strumenti.
Richiesta di esempio
curl -H "X-API-Key: $DOMSCAN_API_KEY" "https://domscan.net/v1/subdomains?domain=example.com"
Risposta di esempio
{
"domain": "example.com",
"subdomains": [
{
"name": "api.example.com",
"source": "ct",
"first_seen": "2026-01-18T09:24:00Z",
"verified": false,
"dns_records": null
},
{
"name": "www.example.com",
"source": "ct",
"first_seen": "2025-11-04T14:10:00Z",
"verified": false,
"dns_records": null
}
],
"summary": {
"total_found": 2,
"returned": 2,
"verified_count": 0,
"unverified_count": 2,
"sources_used": ["crtsh"]
},
"meta": {
"query_time_ms": 842,
"cached": false
}
}
Domande Frequenti
Interroghiamo fonti pubbliche Certificate Transparency come crt.sh e normalizziamo i nomi dei certificati in risultati di sottodomini deduplicati. La verifica DNS opzionale può confermare quali host restituiti risolvono.
Sì. Utilizziamo fonti di dati pubblicamente disponibili (i log CT sono pubblici per design, il DNS è pubblico). Non effettuiamo scansioni attive o enumerazione di brute-force.
I log CT catturano nomi host apparsi in certificati pubblici. È una forte copertura passiva, ma non rivela host solo interni o nomi che non hanno mai usato TLS pubblico.
Un 202 significa che non era pronto alcun risultato di sottodomini in cache per una richiesta cache-only. Abbiamo accodato un aggiornamento in background, restituito Retry-After e addebitato 0 crediti per quella risposta in sospeso.
La scoperta di sottodomini è il primo passo nella valutazione della sicurezza. Trovare sottodomini dev/staging dimenticati o shadow IT spesso rivela debolezze di sicurezza.
Strumenti e Risorse Correlati
Codici di stato HTTP
Documentiamo i codici di stato HTTP che il tuo client dovrebbe gestire per distinguere risposte riuscite, problemi di autenticazione, crediti, limiti di richiesta, dati mancanti ed errori upstream.
Richiesta riuscita
Mancato risultato cache-only per i sottodomini accettato per aggiornamento in background. Non vengono addebitati crediti; riprova dopo il ritardo Retry-After.
Parametri non validi
Crediti insufficienti per eseguire questa richiesta.
Limite di richieste superato
Errore interno
Errore RDAP upstream
Il servizio a monte non è disponibile o sta limitando temporaneamente le richieste.
La richiesta al servizio a monte è scaduta.
Scopri Sottodomini