Quikly Drop

Quikly Drop campaigns feature a finite amount of rewards and/or offers awarded by rank, elapsed time, or randomly.

Drop campaigns are made up of a main screens with three different stats, and one additional component that displays offer details after claiming.

Overview

The basic concept for a Drop campaign is to send a viewer's email address to attempt to claim an offer. If successful, the API returns a unique receiptToken that can be used to fetch offer details, as well as an authToken for the user to be used in subsequent API calls to provide authenticated access on that user's behalf.

Additional fields in the API provide CMS-like data that is helpful when rendering a campaign, including headings, images, fine print, and offer details.

Offer Screen

Use the following query to fetch the content for the initial screen of the campaign. In this way the API acts as a CMS so that a campaign manager can update the promotion titles, fine print, and images from the Quikly admin interface.

1query promoLandingQuery($dealHashid: String!) {
2  quikly(hashid: $dealHashid) {
3    id
4    name
5    description
6    header: customContentFor(key: "embedded_instant_sign_in_header")
7    finePrint
8    buttonText: customContentFor(key: "embedded_instant_sign_in_button_text")
9    image {
10      url(variant: "original")
11    }
12  }

The quikly type refers to the campaign instance.

Claiming an Offer

To claim an offer, send the user's email address to the createEmbeddedClaim mutation. This returns a unique offer identifer (qid) and receiptToken used to securely fetch offer details, as well as the user's authToken which can then be used to identify this user on subsequent interactions with the API via the authorization header.

1mutation createEmbeddedClaim(
2  $dealHashid: String!
3  $email: String!
4) {
5  createEmbeddedClaim(
6    input: { dealId: $dealHashid, email: $email }
7  ) {
8    errors {
9      key
10      message
11    }
12    user {
13      id
14      authToken
15    }
16    order {
17      id
18      qid
19      receiptToken
20    }
21  }
22}

You should store the order's qid, receiptToken and the user's authToken locally.

Fetching Offer Detail

Use the getOrder query to fetch offer details for a user once they have successfully claimed.

1query getOrder($orderId: Int!, $receiptToken: String!, $dealTierId: Int) {
2  order(
3    orderId: $orderId
4    receiptToken: $receiptToken
5    dealTierId: $dealTierId
6  ) {
7    id
8    qid
9    expirationDate
10    itemFullDescription
11    itemInstructions
12    finePrint
13    codes: codesWithLabelsAndBarcodes {
14      instore
15      pin
16      value
17      label
18    }
19    links {
20      id
21      name
22      url
23      position
24    }
25    quikly {
26      id
27      hashid
28      termsUrl
29      congratsMessage: customContentFor(key: "claim_congrats")
30      congratsHeader: customContentFor(key: "claim_congrats_embedded_header")
31      congratsSubheader: customContentFor(
32        key: "claim_congrats_embedded_subheader"
33      )
34      redeemCopy: customContentFor(key: "embed_redeem_body")
35    }
36  }
37}

This example shows how you can fetch content from the Quikly campaign (such as a congrats message or campaign heading) as well as data tied to the individual's offer: one or more offer codes, an expiration date, associated fine print or redemption urls, and more. At this point, referencing the OrderType in the GraphiQL Explorer will be very useful!

Checking Claim Status

A quick way to check if a currently authenticated user has already claimed an offer is to use the alreadyClaimed field on the wantIn type:

1query checkAlreadyClaimed($dealHashid: String!) {
2  quikly(hashid: $dealHashid) {
3    id
4    wantIn {
5      id
6      alreadyClaimed
7    }
8  }
9}

The wantIn type represents the viewer's opt-in to a campaign (stemming from the phrase "I Want In"). It ties a user to a quikly.