Skip to main content
/v1 API soveltaa kahta toisistaan riippumatonta pyyntökiintiötä. Pyyntö hylätään, jos jompikumpi kiintiö on käytetty loppuun. API-avainkohtainen kiintiö seuraa avainta sen käyttöpaikasta riippumatta. IP-osoitekohtainen kiintiö on ainoa kiintiö todentamattomalle liikenteelle ja toinen yläraja todennetulle liikenteelle.
Rajat otetaan käyttöön ennen todennusta, joten myös pyynnöt, joissa on virheelliset tai puuttuvat tunnistetiedot, kuluttavat lähteen kiintiötä. Tarkat numeeriset kiintiöt määrittää operaattori, ja ne voivat muuttua. Jäljempänä kuvattu vastauksen sopimus on vakaa rajapinta, jonka varaan toteutus kannattaa rakentaa.
Todenna jommallakummalla Basic-tunnistetietojen muodolla – katso Pikaopas (apikey:secret tai secret:). Aseta BASE organisaation alueelliseksi isännäksi – katso Alueet.

429-vastaus

Kun kiintiö on käytetty loppuun, API palauttaa koodin 429 Too Many Requests sekä Retry-After-otsakkeen (sekunteina) ja standardin problem-details-rungon:
429 Too Many Requests
Vastauksesta ei käy ilmi, mikä kiintiö käytettiin loppuun. Käsittele jokainen 429 samalla tavalla: odota ja yritä sitten uudelleen.

429-vastausten käsittely

1

Noudata Retry-After-otsaketta

Odota vähintään Retry-After-otsakkeessa ilmoitettu sekuntimäärä ennen uudelleenyritystä. Aiempi uudelleenyritys kuluttaa vain kiintiötä pyynnöillä, jotka hylätään.
2

Kasvata odotusaikaa eksponentiaalisesti toistuvissa yrityksissä

Jos uudelleenyritys hylätään uudelleen, pidennä odotusaikaa ja lisää satunnaista vaihtelua (jitter), jotta rinnakkaiset työprosessit eivät yritä uudelleen samanaikaisesti. Älä koskaan lyhennä palvelimen Retry-After-arvoa paikallisen rajan mukaiseksi. Jos palvelin pyytää odottamaan pidempään kuin uudelleenyritysten kiintiösi sallii, lopeta ja ajoita työ myöhemmäksi.
3

Tasoita pyyntötahtia

Suosi tasaista pyyntötahtia piikkien sijaan. Suurissa lukuoperaatioissa käytä suurinta sivukokoa (limit=500), jolloin kokoelma katetaan vähemmillä pyynnöillä – katso sivutus. Kun useita listauksia käydään läpi rinnakkain (esimerkiksi Power BI -taulut), pidä samanaikaisuus kohtuullisena ja noudata Retry-After-otsaketta, jotta tilapäinen 429-vastaus ei kaada koko päivitystä.
Tämä esimerkki yrittää uudelleen vain 429-vastauksissa GET-pyynnölle, enintään viisi kertaa ja odottaen enintään 60 sekuntia yritysten välillä. Se pysähtyy heti muihin virheisiin. Verkon aikakatkaisut välitetään kutsujalle. Määritä aikakatkaisut ja uudelleenyritysten kiintiöt työkuormasi mukaan. requests tulkitsee lukemisen aikakatkaisun datan vastaanoton enimmäisajaksi, jolloin yhteys on toimettomana, ei kokonaisaikarajaksi. Lataa LIVING_SECURITY_API_KEY salaisuuksienhallinnasta. Asenna requests ennen tämän esimerkin suorittamista. Käytä esimerkkiä kutsumalla get_with_retry("/organization").
Python
Älä kopioi tätä silmukkaa kirjoitusoperaation ympärille. Kirjoituksen jälkeinen aikakatkaisu voi tarkoittaa, että palvelin suoritti kirjoituksen ennen yhteyden katkeamista. Toista kirjoitus vain, kun kyseisen operaation viitteessä on nimenomaisesti kuvattu idempotenssi, ja säilytä sama avain ja sama sisältö. Muussa tapauksessa tarkista resurssin tila ennen uutta yritystä.

Suositeltu päivitysaikataulu

Mitoita päivitystiheys avaimesi kiintiön ja sivukoon mukaan. Suuren kokoelman täydellinen historiallinen lataus on kertaluonteinen kustannus; suosi vakiotilan päivityksissä inkrementaalisia aikaikkunoita, jotta jokainen ajo pysyy selvästi kiintiön alapuolella. Aseta limit=500 aina nimenomaisesti – oletusarvo 25 kasvattaa pyyntöjen määrää moninkertaiseksi.