Skip to main content

Sending cards

There are two ways to send cards to your customers using Atomic:

  • Directly from the workbench.
  • Using the Atomic Action Flow API endpoint.

There is also an option to send test cards to test users, using the test-cards endpoint.

Each of these methods is outlined in the Sending cards tutorial.

Delivery options​

It is also possible to set delivery options for a card. This can be done in two ways:

  • In the workbench when authoring the card. The Authoring cards tutorial describes how this is done in detail.
  • By adding optional key-value pairs in the request body.

Card expiry​

Event metadata may include an expiry for the generated card, as either expires (a datetime) or expiresInterval (a duration). Cards with an expiry set will automatically be removed from the customer’s feed when the expiry is reached. If expires and expiresInterval are both set, whichever results in the earlier expiry will be used.

Learn more about using expires and expiresInterval, including some examples in the Date and time reference guide.

Card expiry is configurable in the workbench, per card template within the Delivery tab. The payload delivery options will take precedence in this case, if specified in both places.

Absolute expiry time​

{
  "cardOptions": {
    "expires": "2020-02-19T22:47:30.596Z"
  }
}

Relative expiry time​

It is also possible to expire a card after a period of time. Note: the expiry period starts when the card creation request is sent, not when the card is published.

{
  "cardOptions": {
    "expiresInterval": "P2D"
  }
}

Complete example of a payload with expiry:

{
  "target": {"usersById": "user1"},
  "payload": {
    "variables": {}
  },
  "cardOptions": {
    "expires": "2020-02-19T22:47:30.596Z"
  }
}

Card embargo​

The API request body may include an embargo. Cards that are generated with an embargo datetime will not appear in the customer's feed until the embargo time has passed.

Learn more about using embargo, including some examples in the Date and time reference guide.

Card embargo is configurable in the workbench, per card template within the Delivery tab. The payload delivery options will take precedence in this case, if specified in both places.

Example of a payload with an embargo datetime:

{
  "target": {"usersById": "user1"},
  "payload": {
    "variables": {}
  },
  "cardOptions": {
    "embargo": "2020-03-19T09:30:00.00Z"
  }
}

Target stream ids​

It is possible to provide one or more targetStreamIds in the payload, in order to have the cards appear in the associated containers within your app. This overrides the default configuration on the card.

Example of an event payload with targetStreamIds:

{
  "payload": {
    "variables": {},
    "target": {"usersById": "user1"},
    "cardOptions": {
      "targetStreamIds": ["RvY2qqw1", "2341zpw9"]
    }
  }
}

Display card only on specific platforms​

Display cards only on specific platforms. This overrides the default configuration of the card.

{
  "payload": {
    "variables": {},
    "target": {"usersById": "user1"},
    "cardOptions": {
      "targetPlatforms": ["Android"]
    }
  }
}

Update / overwrite card content​

By providing the flowInvocationId that was used to send the original card, you can update the variable contents of a card that has already been published.

"flows": [
    {
        "target": {
            "type": "segment",
            "targetSegmentId": "segment1"
        },
        "payload": {
            "variables": {
                "discount": "20 %"
            }
        },
        "flowInvocationId": "flowInvocationId1",
    }
  ]
Last updated on