Skip to main content

The GraphQL endpoint

The GraphQL API has a single endpoint:
The endpoint remains constant no matter what operation you perform.

Retrieving the full access key

In the Stigg app, go to Integrations > API keys. Copy the Full access key of the relevant environment.

Discovering the GraphQL API

GraphQL explorer

You can run queries on real Stigg data using our GraphQL Explorer, an integrated development environment in your browser that includes docs, syntax highlighting, and validation errors.
To authenticate you need to pass the Full access key in the X-API-KEY request header.

GraphQL API playground

Interact with Stigg’s GraphQL directly from your browser.

GraphQL introspection

GraphQL is introspective. This means you can query a GraphQL schema for details about itself. To perform an introspection query, send a POST request to the GraphQL endpoint and include your Full access key using the X-API-KEY header. For example, to fetch all available root types:

Provisioning customers

When a new customer is provisioned within your application (for example: as part of your registration or onboarding process), you should also provision them in Stigg. The customer’s billing information can also be passed to Stigg when a customer is created or updated. When Stigg is integrated with additional service, this information will be propagated to the active integrations. The billing information is not persisted on Stigg’s servers. You can optionally pass subscriptionParams to create subscription for that customer using a single operation. Doing so, will allow Stigg admins to override the requested subscription with no-code from the Stigg app using the product’s Customer Journey configuration. Query
Variables

Updating customers

Customer information can also be updated whenever you like assuming it already exists, for example: In order to update the customer’s email, you only need to send the new email value without the rest of the customer. Due to the fact that the customer’s billing information is not persisted on Stigg’s servers, in order to update it, the entire billing information object must be passed each time. Query
Variables

Getting customer data

Query
Variables

Getting customer active subscriptions

Query
Variables

Getting a subscription

Query
Variables

Provisioning subscriptions

When a customer subscribes to a new plan (free, paid, trial, etc.), provision the subscription in Stigg. Query
Variables
  1. A customer can have both a non-trial (free or paid) subscription and trial subscription to different plans of the same product in parallel - this logic allows customers to trial a higher tier plan, while still paying for an existing plan.
  2. When the customer has a trial subscription for plan X of product A and a new subscription is created for the same plan, the new subscription will be created as non-trial (paid) subscription - this logic follows an upgrade flow of a trial subscription to a paid subscription of a specific plan.
  3. Except in the above-mentioned cases, when a customer has an active subscription for product X, and another subscription for the same product is created with start date S, the existing subscription will automatically be cancelled and the new subscription will start on start date S. It’s also possible to explicitly skip the trial period of the selected plan by providing the skipTrial: true parameter to the CreateSubscription mutation.

Updating subscriptions

Updating an existing subscription, this can be used to update the feature quantity that the customer is subscribed for. Query
Variables

Cancel subscription

Query
Variables
Subscription cancellation will take place according to the defined product behavior.

Getting the entitlement of a customer for a specific feature

Used to check if the customer has access to a feature, the usage limit, and the current usage. Query
Variables

Getting all of the entitlements of a customer

Used to check to what features the customer has access to, the usage limit , and the current usage of each entitlement. Query
Variables

Reporting usage measurements to Stigg

The Stigg API allows you to report usage measurements for metered features. The reported usage will be used to track, limit and bill the customer’s usage of metered features. Stigg supports metering of usage from the following data sources:
  1. Calculated usage - usage that has been aggregated and calculated by your application. This type is useful for features, such as: seats.
  2. Raw events - raw events from your application, which Stigg filters and aggregates aggregate to calculate customer usage. This type is useful for features, such as: monthly active users (MAUs).
More details about Stigg’s metering and aggregation capabilities can be found here:

Stigg's metering and aggregation capabilities

  1. Reporting of measurements to Stigg should be done only after the relevant resources have been provisioned in your application.
  2. To ensure that the provisioned resources are aligned with the measurements that are reported to Stigg, ensure that customers are not allowed to allocate new resources until an acknowledgement about the processed measurement is received from the Stigg backend.
Validating that a measurement was successfully reported to Stigg is also possible in the customer details section of the relevant customer in the Stigg app.

Calculated usage

#Query
#Variables

Raw events

#Query
#Variables
It’s also possible to send a batch of events in one invocation. To do so, simply pass an array of events to the reportEvent method. Response The mutation has no return value

Getting available coupons

Query
Variables

Estimate subscription cost

You can estimate the subscription cost using the estimateSubscription method. This can help the customer to understand the costs before paying. Query
Variables
You can also estimate the cost of updating an existing subscription using the updateSubscription method, which also returns a breakdown of the proration amounts: Query
Variables

Migrating subscriptions to the latest plan and add-on version

When changes to plans and add-ons are rolled out only to new subscriptions, grandfathering takes place. In order to prevent a SKU sprawl, Stigg allows you to manually migrate subscriptions to the latest plan and add-on version on a subscription-by-subscription basis.
When the current price of the subscription is different than the latest published package version, during the migration the customer will be charged or credited the prorated amount until the end of the current billing period depending on whether the latest price is more expensive or cheaper than the current subscription price.
Query
Variables

Archiving & unarchiving customers

When a customer is archived:
  1. Its PII (name and email address) will be nullified.
  2. It will no longer appear in the Stigg app UI.
  3. It will no longer be returned by the Stigg API and SDKs.
When Stigg is integrated with a billing solution, customers that are archived in Stigg will still exist in the billing solution to allow upcoming invoices to be finalized. Archiving customers in the billing solution can be done manually in the billing solution. To archive a customer:
To unarchive a customer:

Full API reference

Stigg GraphQL API reference