Account and document access
Download an existing attachment from a porting project owned by your API account. Use an enabled API account over HTTPS from an allowed IP address. The project must not be deleted. A document ID is looked up within that project; it is not a global public download link.
Identify the document
Read the project detail response and use an entry from its uploads list. The entry includes the numeric id, original file name, stored extension and relative download_url. Use the project’s uniqueid and that upload ID, not the project’s numeric row ID or a number row ID.
Resolve a returned relative URL only against your configured, trusted API host. The download needs the same account authentication; document metadata does not grant unauthenticated access.
Request and save the response
Set PROJECT_ID and DOCUMENT_ID to values from your account’s project. URL-encode the project ID. This example saves bytes and response headers separately, using a fixed local output name rather than trusting the attachment’s file name.
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"The request is GET with no body. It reads a single complete attachment, with no endpoint-specific pagination, JSON wrapper or documented range-download contract.
Binary response and headers
On success, the body is the attachment’s stored bytes after the legacy storage decoding step, not base64 and not a JSON response object. The method sends an attachment Content-Disposition using the stored file name, with double quotes removed. The header is not a guaranteed standards-encoded or safe local file path; choose your own destination file name.
| Stored extension | Content-Type |
|---|---|
| application/pdf | |
| png | image/png |
| jpg, jpeg | image/jpeg |
| doc | application/msword |
| Other values | application/octet-stream |
Extension matching is case-insensitive. MIME selection comes from the stored extension, not content inspection or a guarantee that the document is valid.
Verify the downloaded file
- Inspect both HTTP status and response headers. Authentication or lookup errors can return a JSON API response instead of a file. Do not treat every nonempty body or saved output file as a successful PDF download.
- If the body is a JSON error, inspect
status.codeandstatus.msg. Keep error output separate from the expected document. - Check that the resulting file is nonempty and opens as the expected type. When you retain the original, compare its checksum before relying on the copy.
- If the result is empty, invalid or differs from the original, stop and ask support to check the stored attachment. Repeated downloads do not repair storage.
Legacy storage compatibility
The current API upload path and reviewed portal/legacy upload writers store escaped document bytes. This download reverses that escaping. Offline tests of the actual handler preserve all byte values and literal backslashes for that storage format.
This is not a promise about every historical or externally imported record. The handler always decodes the stored blob and does not detect whether a record was imported without the expected escaping. It also does not fall back to a file path when a record has no stored blob. Such records can produce changed or empty bytes. Verify the result and have support investigate an affected attachment rather than altering a customer document or assuming its metadata proves the file is available.
The current portal uses this API route first and has additional local fallback handling. A successful portal download does not prove that every legacy record can be downloaded directly through this API.
Errors and effects
A missing, deleted or unowned project returns API code 404 with a project-not-found message. A missing upload within an owned project returns API code 404 with a document-not-found message. Read API error bodies as well as HTTP status. A record that exists but lacks useful stored bytes does not have a dedicated reliable not-found response in this handler.
The reviewed endpoint reads one attachment. It does not upload, modify or remove a document, submit a porting request or debit the account. Porting attachments may contain identity, billing or authorization information: keep them within authorized account workflows and out of public logs, analytics and documentation screenshots.