ListMailings -yields error on MailingId being int with error JSON integer 18559069618 is too large or small for an Int32. Path '[0].mailing_id', line 1, position 117.

[MilSix]

Hi Kyle.
I got error JSON integer 18559069618 is too large or small for an Int32. Path '[0].mailing_id', line 1, position 117. on mailing_id when try to call emma api listMailings. Should mailing_id be a long integer instead. Not sure if it was emma bug or just from emmasharp. Can you help?
Thanks
MilSix

[MilSix]

Hi Kyle,
Thank you for a quick update all IDs to long.
Sorry to took so long to test it out. Anyhow, I'm still get the same error after download get the latest version. Since you update all the IDs to long but still for those defaults (to list range of ID still in int such as start , end parameters in ListMailings method.

    public List<MailingInfo> ListMailings(bool archived = false, List<MailingType> mailingType = null, List<MailingStatus> mailingStatus = null, bool isScheduled = false, bool withHtmlBody = false, bool withPlaintext = false, _**int** start = -1, **int** end = -1_)
    {
        var request = new RestRequest();
        request.Resource = "/{accountId}/mailings";

		if (archived)
            request.AddParameter("include_archived", archived);

        if (mailingType != null)
            request.AddParameter("mailing_types", string.Join(",", Array.ConvertAll(mailingType.ToArray(), i => i.ToEnumString<MailingType>())));

        if (mailingStatus != null)
            request.AddParameter("mailing_statuses", string.Join(",", Array.ConvertAll(mailingStatus.ToArray(), i => i.ToEnumString<MailingStatus>())));

        if (isScheduled)
            request.AddParameter("is_scheduled", isScheduled);

        if (withHtmlBody)
            request.AddParameter("with_html_body", withHtmlBody);

        if (withPlaintext)
            request.AddParameter("with_plaintext", withPlaintext);

       ###  **return Execute<List<MailingInfo>>(request, start, end);**
    }

[kylegregory]

@MilSix Right, but int start and int end are the "pages" in the pagination. I wouldn't expect you to have that many mailing records, correct? Must be something else. Also my latest mailing ID is way under the 2.1 billion for int32, so I don't think that was it, though probably not wrong to plan ahead there.

[MilSix]

agree. Our main account has 37 sub-accounts, where each of 37 (colleges-entities) managing their own campaigns. it's only about 6 or 7 of sub-accounts are currently active.
I don't think we have that many campaigns. Don't know how emma store ID, may be they stored all customers email in same table. That would make ID possible with long values. I was hoping to call ListMailings for inventory purposes.

[kylegregory]

@MilSix might be good if you can download and reference the project manually so you can set some breakpoints and investigate. Did the exception thrown change since you updated?

[MilSix]

Exception thrown only when I reach 37th loop. Might be I just going to force it to just use for one sub account and see if I get the correct list. Here is current code. Not sure if I use it correctly, that might be the case too.

    public int ListMailingsCountBySubAccount(List<USR_USP_EMMA_SUBACCOUNT_SP_Result> subAccounts, List<EmmaSharp.Models.Mailings.MailingInfo> outList)
    {
        int mailCount = 0;
        foreach (var subAccount in subAccounts)
        {
            EmmaApi emmasharpRead = new EmmaApi(publicKey, privateKey, subAccount.AccountId.ToString());
            mailCount += emmasharpRead.ListMailingsCount(true, null, null, false, false, false);
            List<EmmaSharp.Models.Mailings.MailingInfo> MasterMailingInfosList = emmasharpRead.ListMailings(true, null, null, false, false, false, -1, -1);
        }
        return (mailCount);
    }

[kylegregory]

@MilSix Ah, I see. Doing that many calls (each emmasharpRead being a call, 2 times a loop) could be getting you rate limited. I ran this code on my end and that's what happened. Emma has a 180 calls/minute limit. Seeing as it's getting to about the same point each time, I'm thinking that might be why.

Might think about splitting the work into separate calls, holding on the count then doing your Listing later. Also if you use each accounts API key rather than your personal, you don't get flagged for as many call hits. Since each account has unique keys, you only get flagged for the calls within the loop. For larger work you may need to consider going this route.

Let me know if that gets you further along.

[MilSix]

Thank you Kyle, that makes sense. Il try to get all sub accounts keys Thought we only have one set keys. for all sub account.