Simon Trigona

When we receive a webhook request, we need to validate it's a real webhook event and not something fake/malicious. We do this by making a getApiSession https://developer.intacct.com/api/company-console/api-sessions/#get-api-session with the session from the webhook request and comparing the results (that it's a valid session + compare the company from the session to the company on the webhook request). I don't think I see a way to perform the above validation through the new REST api. Is this on the roadmap?

Ok great! A few more questions if you don't mind: Can a refresh token be used more than once? If the response for a refresh is lost due to some service disruption (ex: timeout, internet issues, etc.), are we stuck needing to re-authenticate with the client?

I'm in the same boat and as a result, have not seriously looked into switching to the new API. My understanding on the required approach would be something like: Provide a URL/website to your client to run through the authentication flow. Store the generated token for your background service. When it expires, repeat. Provide a URL/website that your client will use to authenticate your app. Have the callback URL setup to your website/service. Capture the access/refresh tokens & store in your database. Use these values as long as you can. When they expire (or proactively before they expire), email your client a notification with the URL from step 1 to re-authenticate. Repeat. That being said, based on reading some other forum posts, if I'm understanding correctly, the refresh token should be refreshed/have its expiry extended by 90 days every time its used. So it should be valid indefinitely. I did ask for clarification on this in the following thread.

Am I reading item 2 correctly, in that the refresh token will expire after 90 days, HOWEVER, every time you use the refresh token to get a new access token, you will get a new refresh token that is valid for another 90 days? In other words, as long as you keep using your refresh token, it will remain valid and you won't have to reauthenticate with your client. If you don't use it for 90+ days, then it'll expire. Would it be possible to get this info added to the documentation site? I assume it would go here: https://developer.sage.com/intacct/docs/developer-portal/guides/security/ Thanks in advance, Simon

Thanks Louis, I did manage to reproduce it in my environment and have opened up a support ticket.

Hi, We're using the Create AR Payment API (https://developer.intacct.com/api/accounts-receivable/ar-payments/#create-ar-payment ) and depending on the state of data in Intacct we get different error messages. Some are clear and one is very ambiguous and I am looking for clarification on what it means/how to reproduce. Given the following payment request, <create> <ARPYMT> <FINANCIALENTITY>100_CHK</FINANCIALENTITY> <PAYMENTMETHOD>Cash</PAYMENTMETHOD> <CUSTOMERID>10001</CUSTOMERID> <DOCNUMBER>test</DOCNUMBER> <RECEIPTDATE>8/1/2024</RECEIPTDATE> <PAYMENTDATE>8/1/2024</PAYMENTDATE> <ARPYMTDETAILS> <ARPYMTDETAIL> <RECORDKEY>167</RECORDKEY> <NEGATIVEINVOICEKEY>64</NEGATIVEINVOICEKEY> <TRX_NEGATIVEINVOICEAMOUNT>5</TRX_NEGATIVEINVOICEAMOUNT> </ARPYMTDETAIL> </ARPYMTDETAILS> </ARPYMT> </create> We may get the follow errors which are very clear The credit amount selected for payment is bigger than the credit amount available. The amount received is greater than the amount to apply. Reduce the amount received, reduce the credit amount to apply, or add an overpayment. Then try again. There is no due on the invoice 167 However we see the following error (where 309789 is the invoice / RECORDKEY) in some of our other environments and I'm not sure what the cause is. Invalid transaction key 309789, No line items found