Åtkomst till konto och dokument
Ladda ned en befintlig bilaga från ett nummerporteringsprojekt som ditt API-konto äger. Använd ett aktiverat API-konto via HTTPS från en tillåten IP-adress. Projektet får inte vara raderat. Dokumentets ID slås upp inom det projektet; det är ingen global, offentlig nedladdningslänk.
Identifiera dokumentet
Läs svaret med projektets detaljer och använd en post i dess uploads-lista. Posten innehåller ett numeriskt id, det ursprungliga filnamnet, den lagrade filändelsen och en relativ download_url. Använd projektets uniqueid och ID:t för den uppladdningen, inte projektets numeriska rad-ID eller rad-ID:t för ett telefonnummer.
Tolka en returnerad relativ URL enbart i förhållande till den betrodda API-värd som du har konfigurerat. Nedladdningen kräver samma kontoautentisering; dokumentets metadata ger inte åtkomst utan autentisering.
Begär och spara svaret
Ange PROJECT_ID och DOCUMENT_ID med värden från projektet som ditt konto äger. URL-koda projektets ID. I det här exemplet sparas byte och svarshuvuden separat, med ett fast lokalt filnamn i stället för att lita på bilagans filnamn.
curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
--dump-header document-headers.txt \
--output porting-document.bin \
"https://api.multitel.net/v3/lnp/project/$PROJECT_ID/document/$DOCUMENT_ID"Begäran använder GET utan meddelandekropp. Den läser en enda fullständig bilaga, utan slutpunktsspecifik sidindelning, JSON-omslutning eller dokumenterat kontrakt för nedladdning av byteintervall.
Binärt svar och svarshuvuden
Vid ett lyckat anrop innehåller svarskroppen bilagans lagrade byte efter avkodningen för det äldre lagringsformatet, inte base64 och inte ett JSON-svarsobjekt. Metoden skickar ett Content-Disposition-huvud för en bilaga med det lagrade filnamnet, där dubbla citattecken har tagits bort. Huvudet garanteras inte vara standardenligt kodat eller utgöra en säker lokal filsökväg; välj ett eget namn för målfilen.
| Lagrad filändelse | Content-Type |
|---|---|
| application/pdf | |
| png | image/png |
| jpg, jpeg | image/jpeg |
| doc | application/msword |
| Övriga värden | application/octet-stream |
Matchningen av filändelser skiljer inte på stora och små bokstäver. MIME-typen väljs utifrån den lagrade filändelsen, inte genom kontroll av innehållet, och valet garanterar inte att dokumentet är giltigt.
Kontrollera den nedladdade filen
- Kontrollera både HTTP-status och svarshuvuden. Autentiserings- eller uppslagningsfel kan ge ett JSON-formaterat API-svar i stället för en fil. Betrakta inte varje svarskropp som innehåller data eller varje sparad utdatafil som en lyckad PDF-nedladdning.
- Om svarskroppen är ett fel i JSON-format, kontrollera
status.codeochstatus.msg. Håll felutdata åtskilda från det förväntade dokumentet. - Kontrollera att den resulterande filen inte är tom och att den öppnas som den förväntade filtypen. Om du har kvar originalet ska du jämföra kontrollsummorna innan du förlitar dig på kopian.
- Om resultatet är tomt, ogiltigt eller skiljer sig från originalet ska du avbryta och be supporten kontrollera den lagrade bilagan. Upprepade nedladdningar reparerar inte lagringen.
Kompatibilitet med äldre lagring
Den nuvarande uppladdningsvägen via API och den granskade skrivkoden för uppladdningar i portalen och äldre system lagrar dokumentens byte med escape-kodning. Den här nedladdningen återställer dessa escape-sekvenser. Offlinetester av den faktiska hanteraren bevarar alla bytevärden och bokstavliga omvända snedstreck för det lagringsformatet.
Detta är inget löfte om att alla historiska eller externt importerade poster fungerar. Hanteraren avkodar alltid den lagrade binärdatamängden och upptäcker inte om en post har importerats utan den förväntade escape-kodningen. Den använder inte heller en filsökväg som reservlösning när en post saknar lagrade binärdata. Sådana poster kan ge ändrade byte eller ett tomt resultat. Kontrollera resultatet och låt supporten undersöka en berörd bilaga i stället för att ändra ett kunddokument eller anta att dess metadata bevisar att filen är tillgänglig.
Den nuvarande portalen använder denna API-rutt först och har dessutom lokal reservhantering. En lyckad nedladdning via portalen bevisar inte att varje äldre post kan laddas ned direkt via detta API.
Fel och effekter
Om projektet saknas, är raderat eller inte ägs av kontot returneras API-kod 404 med ett meddelande om att projektet inte hittades. Om en uppladdning saknas i ett projekt som kontot äger returneras API-kod 404 med ett meddelande om att dokumentet inte hittades. Läs både felkropparna från API och HTTP-statusen. För en post som finns men saknar användbara lagrade byte har den här hanteraren inget särskilt, tillförlitligt svar om att innehållet inte hittades.
Den granskade slutpunkten läser en bilaga. Den laddar inte upp, ändrar eller tar bort något dokument, skickar inte in någon begäran om nummerportering och debiterar inte kontot. Bilagor för nummerportering kan innehålla identitets-, fakturerings- eller fullmaktsuppgifter: hantera dem enbart inom behöriga arbetsflöden för kontot och håll dem borta från offentliga loggar, analysdata och skärmbilder i dokumentation.