The gateway supports both synchronous and asynchronous responses to incoming requests. A synchronous response returns to the client in the same HTTP connection as the request. With asynchronous responses, a client can send multiple requests and receive the responses in subsequent connections.

By default, responses from the gateway are synchronous. If you want asynchronous responses, some additional steps are required.

Synchronous responses

Synchronous responses are typically used when the client must wait to receive the response before processing continues on the client side. A request is processed in real time, and the gateway returns the response via the HTTP connection created by the client. If a validation error occurs, the error is returned synchronously.

Note: Sending a large request can cause the sender process to time out (after 15 minutes) even though the request is still being processed by the Intacct system. You can avoid timeouts using by limiting your calls to a given set of recommendations.

Asynchronous responses

You can work with Intacct to configure asynchronous processing if you do not want your client to wait for responses in the same HTTP connection. Asynchronous responses can be very useful when posting large requests that require significant processing time.

When an asynchronous request is received, a synchronous response is sent either as an acknowledgement of success or as a typical error response. An acknowledgement means that the request was successfully validated and is now queued for processing. When the request is processed out of the queue, a response is returned to the client in a new connection using the response url and credentials supplied in the client‘s transport policy.

You must work with Intacct to create a transport policy in order to use asynchronous processing. Open a support case for help establishing a transport policy.

Once you have the transport policy in place, you provide the transport policy ID in the <control> block of your requests.


The following shows a sample HTTP response with transport policy parameters

Content-Type: application/x-www-form-urlencoded\r\n 
Authorization: Basic XcYtWe34RFgjFG89==\r\n 
Content-Length: 10\r\n\r\n 

Transport policies

A transport policy is an agreement between Intacct and the client describing how the two systems will communicate. A transport policy contains specifications for the response URL, the protocol to use, and the credentials that allow Intacct to establish a connection with the client‘s gateway.

A client may have multiple transport policies, each containing different response addresses and credentials. A transport policy is uniquely identified by its policy ID.

Sample transport policy

Label Sample value
Policy ID: myAsyncDevPolicy
Mode: A
Transport Protocol: HTTP
Response Address:
HTTP User ID: mypartner
HTTP Password: mypartnerpasswd
URL Encode: T
Content Key: xmlresponse
Primary Delimiter: =

Transport policy attributes

Attribute Required? Description Valid Values
Policy ID YES Unique ID identifying the policy 40 alphanumeric characters
Transport Mode YES Mode of response A – Asynchronous
S – Synchronous
Transport Protocol YES Transport protocol of response HTTP, HTTPS, EMAIL, FTP
Response Address YES Address to post response Fully qualified URL (without the protocol)
HTTP User ID NO User ID for server authentication 30 alphanumeric characters
URL Encode Flag YES Indicator flag to determine if response should be url encoded T – yes
F – no
Policy ID YES Unique ID identifying the policy 40 alphanumeric characters
Content Key NO Content key to use when posting the response 40 characters (no special characters)
Content Primary Delimiter NO Key/Value pair delimiter to use when posting the response 1 character

Provide feedback