API downloading invoices / documents

Case Scenario:

When our API is trying to download invoice files we are getting the following error: 

{"Status":500,"ErrorList":[{"ErrorCode":"General_ServerIsExperiencingProblems","Message":"The server is experiencing problems.  Please try again later. Source: ListData","Source":"ListData"}]}

I have checked to see if the document is visible in the folder and it is. 

I am having to create invoice (without printing) as we have to apply a payment (from our previous system) to the invoice before we want to print the PDF. 

This is not the case for all invoices, but we still seem to be getting an error downloading the invoice PDF regardless.

Solution from the customer:

I've done some diagnostic API calls against the Momentus Documents endpoint and believe I've found the root cause. It's not a missing/ungenerated PDF issue, and it affects both internal and external invoices equally.

The problem: Type M vs Type C documents

Each invoice in Momentus has two document records attached with Subject 'INV':

• Type C: the actual PDF file (has a DocumentID like "C0000144.pdf", File Type "application/pdf")
• Type M: a mail merge/email metadata record (empty DocumentID, File Type "Empty Filename", no downloadable binary)

The integration was selecting the Type M record and attempting to download it, which returns a 500 error from Momentus because there's no file to serve.

Why it was picking the wrong one

The document selection logic filters for Subject = 'INV' with a description containing "Invoice", then picks the most recent by timestamp. The issue is that for each invoice, the Type M and Type C records are created at the exact same timestamp (to the millisecond). When timestamps are equal, the sort preserves the original order from the API response. In all 4 failing invoices, Type M appears before Type C in the response (Momentus seems to return them ordered by SequenceNumber, and M has a lower sequence number than its paired C).

So, it was consistently selecting the undownloadable mail merge record over the real PDF sitting right next to it.

Why 30017 happened to work (a coincidence)

Two reasons, either of which alone would have been sufficient:

1. 30017's Type M record is described as "Worldpay Payment Link" rather than "Final Invoice...", so it was already excluded by the description filter
2. Even if it had said "Invoice", the array ordering for 30017 happens to place C before M for the same-timestamp pair, so the correct document would have been selected anyway

The other 4 invoices' Type M records are all described "Final Invoice - ..." or "Final Invoice: ...", which passes the description filter, and their M records appear before their C counterparts in the API response.

The fix

I've added a filter to exclude Type M documents from selection entirely. These are mail merge metadata records and never contain a downloadable PDF. All 4 invoices have valid Type C PDFs ready to go. I confirmed by successfully downloading the Type C document for invoice 30025.