The same custom-subscriber pattern used for Azure Functions applies to AWS Lambda — Acumatica has no AWS-specific integration, so a Lambda endpoint is just another HTTP or queue target that a Business Events custom subscriber calls out to.
Lambda function URLs vs. API Gateway
Lambda function URLs are the simplest entry point — a direct HTTPS endpoint in front of one function, no API Gateway needed. They're a reasonable starting point for a single internal integration. API Gateway in front of Lambda is worth the extra setup once there's more than one event type hitting AWS, or once you need request validation, throttling, or usage plans that a bare function URL doesn't give you.
Authentication: IAM vs. API key
Function URLs support two auth modes: NONE, which is unauthenticated and should not be used for anything real, and AWS_IAM, which requires SigV4-signing every request. Signing a request from a .NET Business Events subscriber means either pulling in the AWS SDK for .NET on the Acumatica server or implementing SigV4 by hand — the SDK is the less error-prone choice if the instance's customization policy allows the extra dependency. Where API Gateway is in front of Lambda, an API key plus a usage plan is often simpler to operate than IAM signing, at the cost of being a static secret rather than a signed request.
var request = new AmazonServiceClient.HttpRequestMessage(HttpMethod.Post, lambdaUrl)
{
Content = new StringContent(JsonSerializer.Serialize(payload))
};
var signer = new AWS4Signer();
signer.Sign(request, region: "us-east-1", service: "lambda",
credentials: awsCredentials);
var response = await httpClient.SendAsync(request);
row.Status = response.IsSuccessStatusCode ? "Delivered" : "Pending";Cold starts, and why they matter here
A cold Lambda invocation can add anywhere from a few hundred milliseconds to a few seconds of latency, depending on runtime and package size. Since the subscriber that calls it runs inline with an Acumatica save (see the Business Events deep dive for why that matters), a cold start turns into a user waiting on their Sales Order save. The fix is the same one that applies to Azure: don't call Lambda directly from the subscriber. Write to a queue table, and let a separate scheduled processor make the call outside the user's request.
If the outbound processor writes to an SQS queue instead of calling Lambda's URL directly, Lambda's SQS trigger gives you configurable retry attempts and a dead-letter queue with zero custom retry code. It's usually less work than building retry logic in the Acumatica-side processor, and it's the AWS-native equivalent of the pattern in the dead-letter queue article.
Mapping Acumatica fields on the way in
Acumatica's contract-based REST API and the fields exposed through a Business Event's source GI don't always use names a downstream system will recognize — ShipmentNbr means nothing to a marketplace API expecting orderId. Do that field mapping in the Lambda function, not in the Acumatica-side payload builder, so a change to the downstream contract doesn't require touching the Acumatica customization project.
Wrapping up
Lambda as a Business Events target is straightforward once the call is decoupled from the triggering save — queue on the Acumatica side, SQS-triggered Lambda on the AWS side, and field mapping kept entirely inside the function.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.