AWS Marketplace Entitlements

AWS Marketplace Entitlements covers the seller-side APIs a SaaS or container product needs at runtime. Workflows resolve a registration token to a customer, check what they are entitled to, and meter usage for billing.

Verified 6 actions Custom auth available

Platform Documentation Capability data verified 2026-08-25

A buyer lands on the product's registration page carrying a marketplace token

Resolve Customer exchanges the token for the buyer's AWS identity and license

Check Customer Entitlement asks what they are actually entitled to right now

The tenant is provisioned at the entitled dimension and the record is written

The revenue operations channel gets the new subscription with its dimensions

A person decides what to do about a buyer whose entitlement check came back false

What This Integration Enables

This connector is the runtime contract between an AWS Marketplace seller and AWS. It is not billing software and it does not hold a ledger. It answers two questions at the moment a buyer arrives, who is this and what have they bought, and it reports back what they consumed. Everything a Marketplace listing promises about entitlement and metered pricing eventually resolves to these six calls, which is why they belong in a workflow rather than buried in a service somebody wrote once and forgot.

FlowRunner agents run the registration handshake and the metering cycle. An agent resolves a registration token the instant the buyer lands, checks entitlement against a specific pricing dimension rather than the whole product, provisions accordingly, and reports usage on the seller side. AWS publishes subscription notifications through its own topic service rather than through this API, so these workflows are started by an inbound registration, a schedule, or an upstream event rather than by the connector listening for one. Where a report reaches a customer's bill with no correction path, human-in-the-loop is the default.

Without FlowRunner

Access decided from a stale copy Entitlement was read once at signup and cached, so an expired customer keeps their access

Metering as an afterthought Usage is summed at month end and reported in one run, with no way to check it first

Registration failures look identical An expired token, a wrong-account credential, and an unsubscribed buyer all read as a broken signup

With FlowRunner

Access decided at the moment of access The entitlement check runs against AWS when the decision is made, with expired records already dropped

Metering is a reviewed process Usage is assembled, checked against the prior period, and reported inside the window AWS allows

Failures are named The exception AWS returns is surfaced as what it means, so an unsubscribed buyer is not treated as an outage

Use Case Scenarios

Registration that resolves at the door

A buyer subscribes on Marketplace and their browser posts a registration token to the product's registration page. The token is short lived and single use, so the agent calls Resolve Customer immediately rather than queueing the work, and gets back the buyer's AWS account, license, and product code. Check Customer Entitlement then confirms what they hold, scoped to the dimension the tenant is being provisioned at. The tenant is created, the record is written to PostgreSQL, and the new subscription posts to Slack with its dimensions named. A token that has already expired produces a specific message rather than a generic signup failure, so support knows to ask the buyer to click through again.
Entitlement checked where the decision is made

Rather than caching an answer at signup, the agent runs Check Customer Entitlement at the point a feature is gated, narrowed to that feature's pricing dimension. The operation pages through every result rather than reading one page, which matters because a single page is not proof of absence, and it drops entitlements whose expiration has already passed. A customer who downgraded loses the higher tier without anybody running a cleanup job. Entitlement reads and their outcomes stream into Datadog so a spike in refusals is visible as a spike rather than as a support queue.
Usage assembled before it is reported

Consumption is aggregated from the product's own telemetry, reconciled against the warehouse table in Snowflake, and compared with the same customer's previous period. Where the figures agree with expectations, the agent submits them with Batch Meter Usage inside the window AWS allows. Where a customer's quantity has moved sharply, the run stops and the comparison goes to a person before anything is reported, because the reporting window closes and does not reopen.

Human-in-Loop Highlight

Batch Meter Usage is the operation with no undo and no second chance, and both halves of that matter. AWS deduplicates identical usage records, so a genuine second report of the same customer, dimension, and timestamp is discarded rather than added, and a quantity already reported cannot be changed afterward. Late records are not deferred, they are refused permanently, with the batch window measured in hours and the month closing at a fixed hour on the first of the next month. Usage that misses it is simply never billed. So a wrong number becomes a wrong customer invoice that neither a correction nor a retry can fix. The agent therefore treats a divergent metering run as an exception rather than a task. It runs Meter Usage in its dry run mode to confirm permissions without recording anything, then posts: "Metering run for the November cycle is assembled. 214 customers match last period within 5 percent. Three do not: Halden Systems is up 11x on the requests dimension, and two accounts report zero after non-zero months. The batch window closes in 6 hours. Submit all, submit the 214, or hold?" A person answers in minutes. What they are protecting is not the workflow, it is somebody else's invoice.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

6 actions

Entitlements

Check Customer Entitlement Answers whether a customer is entitled right now, returning the verdict, the expiry, the dimensions, and the records behind the decision. It pages through every result rather than reading one page, and drops entitlements whose expiration has already passed. Narrowing it to one dimension is how a workflow gates a single feature rather than the whole product.
Get Entitlements The raw AWS listing, returning a page of entitlement records for a workflow to interpret itself. Filter values within one key are combined, while different keys narrow the result, so adding a second key returns fewer records rather than more.

Customers

Resolve Customer Exchanges the registration token the buyer's browser posted for their AWS account identifier, license, and product code. The token is short lived and single use, so this runs at the moment the buyer lands rather than from a queue. The credentials must belong to the account that published the product, which is the usual cause of a valid-looking token being refused.

Metering

Batch Meter Usage Reports usage from the seller side for a SaaS product, up to twenty five records per call for one product. AWS deduplicates identical records, so a retry is safe and a genuine duplicate is silently dropped. Late records are refused permanently rather than deferred.
Meter Usage Reports usage signed with the buyer's own credentials, from the instance, task, or pod role of a running workload. It is the AMI and container operation rather than the SaaS one, allows one report per dimension per hour, and carries a dry run mode that checks permissions without recording anything.
Register Usage Registers a container product's usage at startup. Its not-subscribed exception fires only on the first call from a task or pod, so it cannot be used as a live entitlement check for a customer who unsubscribes while the workload keeps running.

Frequently Asked Questions

What can FlowRunner do with AWS Marketplace Entitlements?

FlowRunner agents can run Get Entitlements, Check Customer Entitlement, and Resolve Customer in AWS Marketplace Entitlements, plus 3 more actions.

Does connecting AWS Marketplace Entitlements to FlowRunner require OAuth?

AWS Marketplace Entitlements uses a custom authentication method to connect to FlowRunner.

Can AWS Marketplace Entitlements trigger a FlowRunner workflow automatically?

AWS Marketplace Entitlements doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with AWS Marketplace Entitlements

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us