/api/search.json voert dezelfde zoekactie uit als het zoekscherm, zie Zoeken, en geeft het resultaat in één antwoord terug in plaats van terwijl er nog wordt gezocht. Het adres is te bevragen zonder account en zonder sleutel.
Parameters
q: de zoekterm. Verplicht; ontbreekt hij, dan antwoordt het adres met status 400;mode: een van vier waarden. Ontbreekt hij, dan geldtall:all: elk woord komt voor in hetzelfde stuk (de standaard);any: ten minste een van de woorden komt voor;near: elk woord staat binnen tien woorden van de andere;exact: de woorden staan aaneengesloten en in precies deze volgorde.
Wat de vier verder betekenen en hoe een bron zonder eigen "of" of "nabijheid" wordt bediend, staat in Zoeken;
page_size:100,500,1000ofmax(het eigen maximum van de bron). Ontbreekt hij, dan geldt de op deze installatie ingestelde standaard,100tenzij de beheerderBesluitBron:Search:PageSizeheeft gewijzigd;date_from,date_to: de grenzen van het datumfilter, in de vormjjjj-mm-dd. Een lege grens laat die kant open;date_undated:1om een treffer zonder datum te tonen zolang het datumfilter aanstaat, dus zolangdate_fromofdate_tois gezet. Zonder een van beide grenzen heeft deze parameter geen effect: dan staat het filter al niet aan en telt elke treffer al mee, met of zonder datum. De werking staat in Zoeken, onder "Filteren op datum";culture: de taal van de uitkomst, de opmerking en de wijze per bron, bijvoorbeeldde. Ontbreekt hij, dan volgt de taal het taalcookie van de aanvrager en andersAccept-Language.
Een ongeldige waarde is een fout, geen stille terugval
Sinds versie 1.3.86 antwoordt het adres met status 400 zodra mode, page_size, date_from of date_to een waarde draagt die niet in de lijst hierboven staat, met een error-veld dat zegt welke parameter het was en een error_description die de toegestane waarden noemt. Bijvoorbeeld mode=xxx of page_size=250 geven zo allebei een duidelijke fout in plaats van geruisloos over te schakelen naar de standaardwaarde. Dat is anders dan het zoekscherm zelf: daar valt een ongeldige waarde in de adresbalk terug op de standaard, omdat een bezoeker een getypte adresbalk zelden nauwkeurig leest en een foutmelding daar niets oplost. Een programma dat dit adres aanroept, kan een eigen fout wél herstellen, dus krijgt het de fout te zien in plaats van een stil gecorrigeerde aanname over wat het bedoelde.
Wat het adres teruggeeft
Eén antwoord met de zoekterm, de losse woorden, de gekozen manier, de duur en, per bron, de uitkomst, het aantal treffers, het totaal dat de bron zelf opgeeft en of dat totaal een telling is of een schatting. De bronnen staan er alfabetisch, niet in de volgorde waarin zij antwoordden: dit adres levert de zoekactie af zodra zij al klaar is, dus is er geen volgorde van binnenkomst om te bewaren.
Elke bron levert ten hoogste het aantal dat page_size vraagt, dezelfde grens die het scherm zelf hanteert. Vraagt page_size meer dan één bevraging van de bron oplevert, dan haalt dit adres zelf meerdere pagina's bij die bron op, tot het gevraagde aantal is bereikt of de bron niets meer heeft, vanaf versie 1.3.86.
Een bron kan een eigen, harde grens hebben die geen page_size kan verhogen: OpenTK bijvoorbeeld geeft nooit meer dan tweehonderdtachtig treffers voor één zoekopdracht. Is dat het geval, dan staat bij die bron at_absolute_ceiling: true in het antwoord, vanaf versie 1.3.86: geen hogere page_size en geen verdere bevraging haalt daar iets extra's uit.
Het gedeelde budget
Dit adres deelt het budget van één zoekactie per seconde met het zoekscherm, want beide bevragen dezelfde bronplatformen. Is dat budget op, dan antwoordt het adres met status 429 en een Retry-After-veld dat zegt hoeveel seconden te wachten.
Wat er wordt vastgelegd
Een aanroep van dit adres wordt op dezelfde manier vastgelegd als een zoekactie op het scherm: één regel per bron in het aanroeplogboek, onder de categorie SEARCH. Zie Privacy en Cookies.