New Source: Sage Intacct

[sherifnada]

Tell us about the new integration you’d like to have

I'd like to be able to pull data from the Sage Intacct API for the following streams:

• Accounts Payable Bills
• Accounts Payable Vendors
• General Ledger Accounts
• General Ledger details
• General Ledger journal entries
• General Ledger Journal Entry Lines
• Projects

There is a Singer tap here which we can use.

We'll first need to create an Intacct account and populate it with data.

┆Issue is synchronized with this Asana task by Unito

[vitaliizazmic]

Integration Vetting

The integration hasn't already been vetted in https://docs.google.com/spreadsheets/d/1CUkw5ha0zPGJT1-vhe2rT3oIWt_6rVieH40J9fVrLJM/edit#gid=0

Webhook-based? (no/partially/yes)

No

Web Services

With Web Services, you can leverage the cloud storage and advanced business logic of the Sage Intacct SaaS framework while providing your own customer-facing web application.

Once integrated, your application can create, update, read, or delete standard or custom objects in a Sage Intacct company (or tenant). Your application interacts with the system through the Web Services gateway using one of the Sage Intacct SDKs or using the underlying XML API framework directly.

Sage Intacct SDKs exist only for .NET, Node.js, PHP.

Endpoint

You use HTTP POST requests to communicate via a unique endpoint. The endpoint is always https://api.intacct.com/ia/xml/xmlgw.phtml initially.

HTTP GET requests are not supported and will be blocked at a future date. Use POST requests only.

Content-Type

All data should be sent encoded as XML with a Content-Type of application/xml. Sage Intacct currently does not support receiving JSON through Web Services.

The XML request

At a high level, the XML document establishes various credentials and provides the API function calls, as shown.

For an in-depth look at each of the elements in the XML request body, see the XML requests topic.

The XML response

By default, the response from the gateway returns to the client in the same HTTP connection as the request, which is known as a synchronous response. You can alternatively configure asynchronous responses according to your application requirements.

A successful request has a response with any number of results, while a failed response contains an error message. Both types of responses are keyed to the request’s control ID.

The response provides a control element and an operation element, just like the request. The control element shows the status of the Web Services authentication at the gateway. The operation element shows the status of the user’s company access and goes on to provide the results for each function call.

For more information, see the XML responses topic.

Current version

All requests sent to the XML gateway should use 3.0 as the value in the control block’s dtdversion element.

The legacy version 2.1 is still supported, however it will likely not receive new product enhancements.

Available authentication modes (API key/Oauth/other)

A Web Services request requires two levels of authentication:

• Web Services credentials
• Company credentials

Web Services credentials

Web Services credentials consist of a sender ID and password. These are provisioned by Sage Intacct for customers/partners with an active Web Services developer license.

These credentials are not necessarily tied to a particular Sage Intacct company/user. A Marketplace Partner can use a sender ID for any Sage Intacct company that has authorized that sender ID for Web Services.

Company credentials

Company credentials consist of either:

• A company ID, user ID, and password - this is called login authentication.
• A temporary session ID - this is called session authentication.

Both of these approaches are tied to a set of company credentials. It is strongly recommended that you set up a Web Services user account in the Sage Intacct UI for this purpose (Company > Web Services user).

Login authentication

Although you can send all requests using login authentication, this is not recommended. You should use getAPISession to request a session ID and unique endpoint, then make all subsequent requests with this context.

Session authentication

A session ID is always tied to a set of company credentials and is the preferred way to make repeated Web Services requests. Session IDs can be generated and sent in a variety of ways:

• Smart events
• Triggers
• UI events

The response for every API call includes the projected session timeout in the authentication element—for more information about session lifespan and timeouts, see API Sessions.

Warning: Regardless of how you receive a session ID, you should call back with a getAPISession function to validate the session and retrieve an appropriate endpoint. Do not blindly trust session IDs that your server receives over the internet. You should also validate that endpoints are *.intacct.com domains.

Creating an account

You must have an active Sage Intacct Web Services developer license, which includes a Web Services sender ID and password. A sender ID can be authorized for more than one company and can be tracked through an audit history report. If you need a developer license, contact your account manager.

In addition, the administrator for the target company must:

• Enable the Web Services subscription using Company > Admin > Subscriptions.
• Authorize your Web Services sender ID for the company.
• Create your user ID. Typically, this will be a Web Services user account, which does not include UI access (see Web Services users in the Sage Intacct product help).

It is needed to request for pricing

How to populate the account with data?

It can be done entirely through the API

Available streams for sync

Sage Intacct has a big amount of endpoints. Full list of APIs divided by groups you can find in reference API.

Integration supports incremental sync?

Some

[sherifnada]

@vitaliizazmic since it's needed to reach out to the company to create an account/request pricing, please make sure to tag @johnlafleur and assign the issue to him so he can move it forward as noted in the vetting template.

@johnlafleur : see the Creating an Account section above -- looks like we need to reach out to create an account

[sherifnada]

cc @arhip11 about the comment above -- if we need to reach out to a company to get an account, we should to tag john and move the issue to "Blocked on Airbyte support" in the project column

[johnlafleur]

Reached out to their partnership team. Will keep you posted.

[johnlafleur]

We have a call tomorrow with their partnership team.

[johnlafleur]

So...to get a sandbox account, we'd need to pay $2,500 annually.
A perk is that we'd be featured as partners on their site, but there is no other path to get the sandbox account.
What I suggest is to see with one of our users if they can give us access to their account so we can build the connector. And once we start to have some revenue model, we'd switch to the partner program. Wdyt?
If you agree, I know 2 users that requested this connector.

[sherifnada]

What I suggest is to see with one of our users if they can give us access to their account so we can build the connector. And once we start to have some revenue model, we'd switch to the partner program. Wdyt?

This sounds like a good path forward. Let's support this once someone actually asks for it.

[jdoit18950]

I am happy to give access to our developer account. Let me know if this is something you are interested in.

[haithem-souala]

Any ETA?

[OmriKeret]

Is this in queue?

[data-use-paragon]

Is this in the pipeline? Would love to be able to use this connector.