Controlla lo stato del servizio in tempo reale e le risposte di errore documentate prima dell’integrazione.
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
/v1/subdomains/bulk
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
Inizia con crt.sh e usa fonti passive alternative quando la fonte principale è vuota o non disponibile.
Usa prefer_cache=1 per fornire solo dati nella cache. Un mancato risultato restituisce 202, accoda un aggiornamento e rimborsa i crediti della richiesta.
DomScan non cerca etichette con la forza bruta, non esegue scansioni delle porte e non esplora il sito target.
Esamina le evidenze pubbliche di possibili nomi host dimenticati o di shadow IT.
Usa le evidenze sui nomi host restituite come uno dei segnali di una verifica di sicurezza autorizzata.
Le voci basate su CT indicano il primo valore not-before del certificato trovato. Le fonti passive alternative possono restituire null.
I mancati risultati in modalità solo cache restituiscono 202 con Retry-After. Se tutte le fonti non funzionano e manca una vecchia cache, la risposta è 503. I crediti vengono rimborsati in entrambi i casi.
Esamina source, first_seen, verifica, wildcard, cache e copertura nel JSON.
Richiesta di esempio
curl -H "X-API-Key: $DOMSCAN_API_KEY" "https://domscan.net/v1/subdomains?domain=example.com&sources=ct&verify=yes&include_wildcards=yes"
Risposta di esempio
{
"domain": "example.com",
"subdomains": [
{
"name": "api.example.com",
"source": "crtsh",
"first_seen": "2026-01-18T09:24:00Z",
"verified": true,
"dns_records": {
"A": ["192.0.2.10"],
"CNAME": null
}
}
],
"wildcards": [
{
"pattern": "*.example.com",
"source": "crtsh",
"first_seen": "2025-11-04T14:10:00Z"
}
],
"summary": {
"total_found": 1,
"returned": 1,
"verified_count": 1,
"unverified_count": 0,
"sources_used": ["crtsh"],
"apex_included": false,
"wildcard_suppressed_count": 1,
"wildcard_returned_count": 1
},
"intelligence_summary": {
"data_sources": ["crtsh"],
"source_count": 1,
"cache_status": "live",
"returned_count": 1,
"total_found": 1,
"truncated": false,
"limit": 500,
"verification_requested": true,
"include_wildcards": true,
"verified_count": 1,
"verified_ratio": 1,
"live_dns_record_count": 1,
"apex_included": false,
"wildcard_suppressed_count": 1,
"wildcard_returned_count": 1,
"first_seen_oldest": "2026-01-18T09:24:00Z",
"first_seen_newest": "2026-01-18T09:24:00Z",
"warning_count": 0
},
"meta": {
"query_time_ms": 842,
"cached": false
}
}
Domande Frequenti
Il selettore di compatibilità sources=ct avvia una pipeline sequenziale. DomScan interroga prima crt.sh, quindi può interrogare HackerTarget, ThreatMiner, Wayback Machine e CertSpotter. La verifica DNS facoltativa controlla solo i nomi restituiti e non ne scopre altri.
L’endpoint consulta set di dati pubblici e, quando richiesto, invia query DNS solo per i nomi già trovati. Non cerca etichette con la forza bruta, non esegue scansioni delle porte e non esplora i siti target. Sei responsabile dell’uso dei risultati nel rispetto della tua autorizzazione e della legge locale.
No. Ogni fonte passiva presenta lacune. Possono mancare nomi interni, host assenti dai set di dati delle fonti e nomi che non sono mai comparsi in certificati pubblici o archivi web. Considera la risposta come evidenza, non come inventario completo.
Una risposta 202 indica che per una richiesta solo cache non era disponibile alcun risultato recente o vecchio. DomScan ha accodato un aggiornamento in background, restituito Retry-After e rimborsato i crediti della richiesta.
No. L’endpoint restituisce evidenze sui nomi host e una risoluzione DNS facoltativa. Non verifica la presenza di vulnerabilità negli host restituiti.
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
Chiave API o sessione mancante o non valida.
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