Ben Smith

Great stuff, glad you're moving forward 😊 Ben

Hi Reginald, So is the JSON response held in the variable 'contactcontent' correct? Ideally if we could see the value of that variable, to verify the response has been successful that would be a good start. Also as far as I can tell from that, you would need to have defined getters and setters for all of the properties you wish to have available on the SageOneContactRootobject object? It appears in your class definition for SageOneContactRootobject you aren't? If thats correct then you should just be able to use the values of the properties on the newly populated object (SageOneContactRootobject.id etc).

Hi, just to add to this - invoicing in Start is significantly more simplistic than in the other variants, allowing the following to be included: Contact Invoice date Reference Description Category (ledger id) Price/net amount VAT rate Total You can then add Notes, and Terms & Conditions etc. I think the ideal solution would be for you to check the variant that a person is using via the businesses/{id} endpoint to check the subscription they have as part of the initial authorisation process/integration: "subscriptions": [ { "created_at": "2017-06-06T08:25:46Z", "updated_at": "2017-06-14T14:28:32Z", "displayed_as": "Accounting", "id": "ACCOUNTING", "active": true, "status": "trial", "accountant_pays": false } ], … This will enable you to change how you post sales invoices and prevent the posting of other transaction types for users of Accounting Start. Hope this helps, Ben

Hi Andrew, Thanks for this clarification. Unfortunately the reconciled flag isn't something currently exposed via the API. There is the bank reconciliations endpoint yes, but that will only allow you to retrieve existing ones and create a new reconciliation, but not include any transactions - which is something I will be chasing up to address. This isn't ideal to be missing, and so will feed this back to the engineering team responsible.

Hi Stuart, Glad thats helping! I'd initially recommend having a look at our Sample app for C#.NET Core and another provided by Ledgerscope, both of which you can download here: https://developer.sage.com/accounting/guides/getting-started/sample_apps/ The Ledgerscope app retrieves all of the response attributes using properties and handles them in an PagingHandler class - definitely worth a look. Ben

Hi Christopher, Whilst I haven't tried, I do not believe its possible to use a lambda function and specify a callback url? Stuart's point is a good one, that if you can handle the initial authentication to retrieve a valid refresh token elsewhere, then use that in the url-encoded body of a refresh request as per our authentication guide, that will likely work. POST https://oauth.accounting.sage.com/token Content-Type: application/x-www-form-urlencoded client_id=4b6xxxxxxx710 &client_secret=iNuxxxxxxxxxxtm9 &grant_type=refresh_token &refresh_token=eyJxxxxxxxxxxYLk Ben

Hi Noland, Good news! We've got a fix for this being deployed early next week - so if you could try it again for me on Tuesday 2nd March and let me know your issue is resolved that would be great Ben

Morning Stuart, So as you've no doubt noticed the links array isn't exposed on the products endpoints, and so you cannot obtain the id you are looking for through that method. However, after doing some digging and discussing this with our API dev team, I've found out that we have a query param that you can use anywhere you see that id used in the URL of show_legacy_id=true. This adds the attribute legacy_id to the response body either when used on a GET to all /products?show_legacy_id=true (the id is displayed for each product/service etc) or when you do a GET on products/{id}?show_legacy_id=true. { "$total": 4, "$page": 1, "$next": null, "$back": null, "$itemsPerPage": 20, "$items": [ { "legacy_id": 3605378, "id": "92b7697e4a9211e796210a57719b2edb", "displayed_as": "Product used for test purposes", "$path": "/products/92b7697e4a9211e796210a57719b2edb" }, { "legacy_id": 5107040, "id": "8c9ecb543d6111e8b45c048132dab352", "displayed_as": "Stock test", "$path": "/products/8c9ecb543d6111e8b45c048132dab352" }, This works on the /contacts endpoint as well just so you know. It will be far simpler to get the id you want using this method, rather than the href I would also add that as these ids were used in earlier versions of the API and so I cannot guarantee it will always work this way, but we will document any changes if or when they were to happen. Ben

Hi Stuart, If you want to create a proforma invoice, you can use the /sales_invoices endpoint, but ensure you populate the status{} array with an id of `PRO_FORMA` "status": { "id": "PRO_FORMA", }, We have a good guide on all things invoicing in our Key concepts series you can find here: https://developer.sage.com/accounting/guides/concepts/invoicing/ This details how to update the status of a draft, or pro-forma invoice to change them to full invoices etc. also. Ben

Thanks for updating that Stuart. I've been trying to establish the steps I'd go through if doing the same. Glad you have got moved forward Ben

Hi Andrew, We're looking into this and will let you know as soon as we have some details for you. Ben

Hi Jason, As Stuart has mentioned there is a RESTful API for Sage Business Cloud Accounting, (the docs of which you found https://developer.sage.com/api/accounting/quick_start_guide/) which might be worth considering? You can have a look at the product details here: https://www.sage.com/en-gb/sage-business-cloud/accounting/ Alternatively, whilst there isn't a RESTful API for Sage 50cloud Accounts, if its a requirement for your integration we do have a .NET SDK that members of our UK Developer Programme can work with. I'd advise contacting our Developer Services team at [email protected] who can discuss your options. Ben

Thanks for letting us know Reginald. Ben

Hi both, I can fully appreciate the issue with different ids being used in different places. I cannot give you an explanation on the why, but can see what I can do to help give you options for working around this. In terms of the contacts endpoint and the reference/id used in the url - it is different to whats used in the API, but its obtainable with a second request. As you are persisting the contact_id against the customers in your system, you would need to make a GET request to /contacts{id} and nested within the links array of the response you will see the `href` property. That gives the link as shown in the URL bar of the contact within the Accounting web UI. I fully appreciate this is not ideal, and will feed this back - we need to have consistency in the way this sort of thing is handled. In respect of the sales invoice reference you want to use, you do still have the property of reference that is independent of the invoice_number field which you should be able to continue to use like you did with Sage 50cloud Accounts, as its just a string that takes up to 25 characters. Ben

Hi Reginald, Thanks for letting us know! Ben

Hi Noland, Just a quick update to say that I've raised this with our dev team and we will be looking into this and will see what we can do. I'll let you know as soon as I have an update! Ben

Hi Noland, Thanks for bringing this to our attention - I'll look into it and let you know as soon as possible how best to handle this. Ben

*Update* Just so that anyone else looking at this post is made aware, If you are looking to make a POST request to create a product that should be a STOCK_ITEM, you must use the /stock_items endpoint. This means you don't need to pass a catalog_type_id and it will 100% be a stock item. When the endpoints were exposed we have different ones for products and stock items. The catalog_type_id isn't exposed via the /stock_items endpoint, but you can see the product also via the /products endpoint, which does expose the catalog_type_id and will show a "STOCK_ITEM". Any questions please reach out, Ben

Hi John, Welcome to the community! At present this is the only way you can handle the initial authentication process, and it will require a manual login. That being said, once an app has been has been authorised once and an access token retrieved it's possible to maintain the connection by utilising the refresh token to request a new access token when the previous has expired. You would need to retrieve the token expiry time during auth, and store the refresh token which has a lifetime of 31 days. If the access token has expired, simply refresh it using the refresh token, and repeat. This would mean that once your initial integration is complete, the process wouldn't require any manual input from a user. We have a thorough guide on the authentication process on our developer portal which you can find here: https://developer.sage.com/accounting/guides/authenticating/authentication/ I hope this helps, Ben

Fantastic, really glad you got it working and thanks a lot for confirming the issue. Good luck with your integration! Ben

Ok, thanks for the update - if you clear all cookies in Postman then try again what do you get? Ben

Hi Christian, The trial account is 100% usable via the API, I've sent you a private message asking for your email address for the accounting business and I can extend that for 12 months for you free of charge. Looking closely at the postman variables - it looks as though the client_secret isn't being passed as a valid variable. It shows in red on the token auth screen - when you look at your variables it looks like there might be a line break character showing (I've attached a screenshot of what I mean). Can you clear the variable name, and try it again for me please? Ben

Hi Kelvin, I can confirm that yes we are 100% working on analysis codes being exposed via the API. However, enabling this functionality is part of a major re-write of the feature and work is ongoing. I would add that I can fully appreciate the issues this causes, particularly where this kind of departmental recording and reporting is a requirement, and I apologise that it isn't available yet. As a team we are trying to improve Accounting and its API and make it the best it can be for you as a developer but also to add as much value as possible for our mutual customers, so this kind of feedback is always welcome and appreciated. I'll take this feedback up the chain and if I can update you with anything I'll let you know. Ben

Hi Christian, Welcome to the community! 9 times out of 10, the error you have received relates to an issue with the callback URL you are using during authentication. Can I confirm you have: Access to a trial account for Sage Business Cloud Accounting (with the required permissions - you might need to speak to your coworker to confirm that in Settings > User Management (ideally ensure that they have given you full access). Registered an application in our app registry (https://developerselfservice.sageone.com/) - the callback URL you enter here must be exactly the same as you pass during authentication. How are you using the API currently, are you scoping it out using Postman or in your own application? Also, do you have an accounting business associated with the email address you are using to authenticate with? Thanks, Ben

Thanks a lot for the feedback Andrew, its really appreciated! Good luck with the rest of your integration, Ben