Marketplace Fulfillment¶

Sell your Omnistrate-hosted SaaS Product through the AWS, Azure and Google Cloud marketplaces. A buyer purchases on the marketplace, Omnistrate creates their organization and tenant identity, and then waits for you to confirm before anything is provisioned. You keep ownership of onboarding.

This section covers the integration itself. For background on what cloud marketplaces are and why you would list on one, see Cloud Marketplace Integrations.

The Two Channels¶

Omnistrate connects to marketplaces through channels. Two exist today, and they are deliberately the same machinery:

The sandbox is not a mock. It runs the same workflow, sends the same signed payloads, and moves a contract through the same states as Suger does. What you certify against in the sandbox is what production sends. That is the point of it: an integration verified against a mock proves only that the mock agrees with itself.

Why Suger¶

Omnistrate fulfills marketplace contracts through Suger rather than integrating with each cloud separately. You list once and reach buyers on all three clouds, Suger owns the listing registration and the cloud-side fulfillment callbacks, and neither you nor Omnistrate has to hold a marketplace credential per provider. Every payload from a real purchase carries "channel": "SUGER".

What happens when someone buys¶

1. A buyer completes a purchase on AWS, Azure or GCP.
2. The marketplace hands them to Suger, which redirects their browser to your Omnistrate landing URL with an entitlement reference on it.
3. Omnistrate reads the contract from Suger: who bought, which plan, how many seats, on what term.
4. Omnistrate creates an organization for the buyer, a root user inside it, and a subscription request in PENDING against the plan they bought.
5. Omnistrate hands the buyer off to you, and waits.
6. You provision your tenant and call confirm. That approval is what creates the subscription.

Until step 6, no subscription exists and the buyer cannot deploy anything. That is deliberate: the buyer is already paying from the moment of purchase, and you decide when they are ready to be served.

Two states, and they are not the same¶

Every contract carries two states, and confusing them is the most common integration mistake.

• contractStatus is what Suger and the cloud marketplace say. A contract is normally ACTIVE from the instant of purchase.
• fulfillmentState is what Omnistrate decided. It governs whether the buyer can deploy and be metered.

A contract sitting at contractStatus: ACTIVE and fulfillmentState: AWAITING_ISV is a buyer who is paying and cannot yet be served. Branch on fulfillmentState, never on contractStatus.

How you are told a buyer arrived¶

You choose one of two delivery paths when you connect the channel, and the choice is the Receiver URL field:

• Leave it empty and the handoff credential rides the buyer's browser. Omnistrate redirects them to your callback URL with ?code= appended. This is the simplest integration and needs no webhook endpoint at all.
• Set it and Omnistrate posts a signed contract.discovered webhook to it instead, server to server. This is also the only way to receive anything after the purchase, because a seat change, a suspension or a cancellation has no browser to ride on.

Not both. Whichever you configure is the one used. See Where buyers go, and how you are told.

Where to start¶