Udviklere

GET/v3/cdrs

Læs kontoens opkaldsposter

Hent de understøttede poster for indgående og udgående opkald i standardperioden, og forstå begrænsningerne for rapportering.

På denne side
  1. Hent kontoens opkaldsposter
  2. Anmodninger
  3. Standardperiode for rapportering
  4. Svar
  5. Felter i posterne
  6. Fejl og begrænsninger for rapportering

Hent kontoens opkaldsposter

Læs poster for indgående eller udgående opkald på din API-konto. Disse poster indeholder private oplysninger om opkald og fakturering. Hold dem inden for autoriserede arbejdsgange på serversiden, og undgå unødvendig logning eller deling.

Dette ældre slutpunkt har i øjeblikket en fast standardperiode og ingen sideinddeling. Brug portalens arbejdsgang til opkaldshistorik og eksport, når du har brug for en anden rapporteringsperiode eller store eksporter af historiske data; brugerdefinerede datoparametre i dette slutpunkt er ikke pålidelige.

Anmodninger

Autentificer dig via HTTPS med din aktiverede API-konto fra dens tilladte kilde-IP-adresse. Eksemplet bruger legitimationsoplysninger i miljøvariabler. De understøttede anmodninger for standardperioden kræver ingen anmodningskrop.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  https://api.multitel.net/v3/cdrs
Stier til anmodninger om opkaldsposter
StiOmfang
/v3/cdrsKontoens poster for indgående opkald i standardperioden.
/v3/cdrs/{number}Poster for indgående opkald, hvor nummeret svarer nøjagtigt til det angivne nummer. Brug helst hele den cifferfølge, der anvendes i din nummeroversigt.
/v3/cdrs/all/outboundKontoens poster for udgående opkald i standardperioden. Behandlingsgrenen for udgående opkald ignorerer det første stiargument; all er her en pladsholder, ikke et jokertegn for indgående opkald.

Brug præcis retningsværdien inbound eller outbound som vist ovenfor. Behandlingsgrenen for udgående opkald implementerer ikke filtrering efter det enkelte nummer. Hvis du føjer et nummer til denne sti, begrænser det ikke resultaterne for udgående opkald.

Standardperiode for rapportering

Forespørgslen begynder ved midnat på den kalenderdato på serveren, der ligger 30 dage før i dag, og slutter ved midnat ved begyndelsen af i dag. Den omfatter derfor ikke resten af den aktuelle dag. Dette er ikke en glidende periode på 720 timer, der slutter på det aktuelle tidspunkt.

Den nuværende implementering understøtter ikke formularfelterne date_from/date_to pålideligt: Når der angives brugerdefinerede datoer, bliver dens variabler for partitioneringsår ikke sat. Brug ikke disse felter til en rapport i produktion. Datoer i forespørgselsstrengen og parametre til sideinddeling er ikke implementeret som alternativer.

Svar

Kun udvalgte felter for indgående opkald vises som illustration; dette er fiktive data og ikke hele den returnerede post.

{
  "status": {
    "code": "200",
    "msg": "",
    "results": 1
  },
  "response": [
    {
      "number": "12025550123",
      "callerid": "12025550124",
      "disposition": "ANSWERED",
      "billseconds": "60",
      "billcost": "0.0100",
      "callsid": "11111111111111111111111111111111",
      "date_created": "2026-10-01 12:00:00 UTC"
    }
  ]
}

response er en liste. Den fælles svarstruktur kan indeholde status.results som antal rækker. Resultatkoder kan være strenge. Et resultat uden poster bruger API-koden 404 med meddelelsen No entries found i stedet for en tom liste med successtatus.

Felter i posterne

Vigtigste returnerede felter
FelterBetydning
number, calleridNummeret for det indgående opkald og identifikatoren for den, der ringer, i feltudvalget for indgående opkald.
calling, called, calleridIdentifikatorer for den opkaldende og den kaldte part i feltudvalget for udgående opkald. Udled ikke en verificeret abonnentidentitet af opkalds-id'et.
disposition, billseconds, billcostGemt opkaldsudfald, faktureret varighed og gemt faktureringsbeløb. Værdierne kan bruge ældre strengformater fra databasen.
callsidOpkaldets gemte UUID til sammenkædning af relaterede data.
date_createdEn dato- og tidsstreng med det bogstavelige suffiks UTC, frem for et garanteret ISO8601-tidsstempel. Fortolk det returnerede format eksplicit.
Andre felterPoster for indgående opkald indeholder også diagnostiske oplysninger om fejl, omkostninger, kanal, kvalitet og oprindelse; poster for udgående opkald indeholder diagnostiske oplysninger om termineringsregionen. Det fulde svar kan indeholde oplysninger om infrastrukturen og bør behandles som privat.

Slutpunktet tilføjer ingen eksplicit sortering eller sideinddeling. Antag ikke, at de nyeste resultater kommer først, at rækkefølgen er stabil, eller at der findes en markør til inkrementel synkronisering. De returnerede faktureringsfelter er gemte opkaldsposter, ikke et pristilbud på et fremtidigt opkald.

Fejl og begrænsninger for rapportering

Læs både HTTP-status og status.code/status.msg i JSON. Hvis der ikke er nogen poster for den valgte konto og periode, returneres API-koden 404. Krav om autentificering og begrænsninger for kilde-IP-adresser gælder også. En stor rapport uden sideinddeling eller en upålidelig anmodning med brugerdefinerede datoer kan mislykkes; gentagen forespørgsel på hele tabellen er ikke en strategi for inkrementel eksport.

Den gennemgåede anmodningsbehandler indeholder læseforespørgsler og hverken debiterer kontoen eller starter opkald. En returneret post beviser ikke, at en person besvarede opkaldet; fortolk det gemte opkaldsudfald og den gemte varighed ud fra formålet med din rapportering.