FlowRunner
PricingContact
Theme
Start Free

Reward Sciences

Loyalty & Referral

Track customer activity for loyalty and rewards with the Reward Sciences API, recording the actions that earn credit. Agents log qualifying events from the systems where they actually happen.

4 actions API key available
A payment succeeds in Stripe for an email the rewards programme has not seen before
Agent calls Get User By Identity for the payer email and again for the CRM record ID
Agent compares what came back to judge whether the two identifiers belong to the same person
Agent calls Track Activity so the purchase earns credit under the profile it is confident about
When the match is plausible but the evidence is thin, the agent stops before Add User Identity and asks a person to confirm the merge

What This Integration Enables

Reward Sciences is not a campaign builder and has no storefront your customers log into. It is a headless activity sink with an identity graph behind it, and that is the whole point. You define the rules for what earns credit inside Reward Sciences. This connector is how the events that satisfy those rules actually arrive, from the systems that observed them.

Four actions cover the entire surface, which tells you something honest about the product. An agent records an activity for a customer with a free-form activity type you define, such as bought-coffee or attended-event, and the customer is created automatically if the programme has not seen them. It resolves your own system's identifier into the internal user ID, enrols someone before any activity exists for them, and attaches an additional identity so the same human being is recognised across email, your CRM and a social login. Small surface, one hard problem: making sure the person earning the credit is the right person.

Without FlowRunner

Earning events stranded in source systems The purchase happens in billing, the event attendance in the ticketing tool, and neither reaches the rewards engine
One person, several profiles The same customer earns separately under an email, a CRM ID and a social login
Backfilled by batch export Activity arrives on a nightly file, so a balance is always a day behind what the customer did

With FlowRunner

Events posted where they happen Track Activity fires from the system that observed the action
Identities resolved deliberately Profiles are merged on evidence and confirmed by a person when the evidence is weak
Balances current Credit accrues at the moment of the qualifying event rather than on the next batch

Use Case Scenarios

Purchases posted from billing, not from a file

A payment succeeds in Stripe. The agent takes the payer email, calls Get User By Identity to resolve it into a Reward Sciences user, and calls Track Activity with a bought-product activity type and the order value. If the person is not yet in the programme, Track Activity enrols them as part of the same call, so a first-time buyer starts earning on their first purchase instead of after someone notices them. The customer's balance reflects the purchase within seconds of the card clearing.

Enrolment ahead of the first activity

Someone completes a signup form in Typeform that is not itself a rewardable action. The agent calls Create User By Identity to enrol them under their email, which returns the new user ID. That ID goes back into the CRM record, so every downstream flow can reference the rewards profile directly without a lookup. The person exists in the programme before they do anything, which makes the first real activity clean.

Non-transactional activity from wherever it happens

Reward Sciences accepts any activity type you define, which means the earning surface is not limited to purchases. An agent watching an events platform records attended-event when a badge is scanned. An agent watching a community forum records answered-question. An agent watching a support queue records completed-onboarding-call. Each one is a Track Activity call from the system that saw it happen, and the rules engine decides what each is worth. No nightly export, no reconciliation job.

Human-in-Loop Highlight

The consequential call in this connector is not recording an activity. It is Add User Identity. Attaching an identity to an existing user tells Reward Sciences that two identifiers belong to the same human being, and from that moment their activity histories and earned balances are one profile. There is no unmerge action in this connector. If the agent is wrong, one customer has inherited another customer's rewards and the only fix is manual work inside Reward Sciences. So the agent treats a fuzzy match as a stopping condition. When a CRM contact and a social login share a surname and a company domain but not an email address, it does not guess. It calls Get User By Identity on both, assembles what each profile has done, and asks the programme owner directly: "CRM contact 88213 and the Google login for [email protected] look like the same person. Profile A has 14 recorded activities since March, profile B has 2. Merging is not reversible here. Same person, or leave them separate?" The person answers, the agent acts. This is what a human-in-the-loop step is for: a small number of irreversible decisions, handed to someone who can actually make them, while the thousands of clean activity records flow through untouched. FlowRunner's connectors are built and verified against each vendor's official API, so the agent knows exactly which calls carry that weight and which do not.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via email
Human decides
Agent resumes with decision

Agent Capabilities

4 actions

Activity

1
  • Track Activity Records an activity for a customer so the loyalty rules can award points or rewards for it. The customer is identified by an identity provider name and their identity within it, and the activity type is a free-form slug you define, such as `bought-coffee` or `attended-event`. Creates the customer automatically if they are not yet known, which makes it safe to fire on a first-time buyer.

Identity

3
  • Get User By Identity Looks up the Reward Sciences user ID for a customer from an identity provider and their identity within it, such as their email address. Used to resolve your own system's identifier into the internal user ID before recording anything further.
  • Create User By Identity Creates a Reward Sciences user for a given identity provider and identity, returning the new user ID. Used to enrol someone into the programme before any activity has been recorded for them, so the profile exists when the first real event arrives.
  • Add User Identity Attaches an additional identity to an existing user so the same person is recognised across several systems, such as email, your CRM and a social login. Used to merge identities onto one rewards profile, and the one call in this connector that belongs behind a human decision when the match is not certain.

Frequently Asked Questions

What can FlowRunner do with Reward Sciences?

FlowRunner agents can run Track Activity, Get User By Identity, and Create User By Identity in Reward Sciences, plus 1 more action.

Does connecting Reward Sciences to FlowRunner require OAuth?

No. Reward Sciences connects to FlowRunner with an API key, no OAuth flow required.

Can Reward Sciences trigger a FlowRunner workflow automatically?

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

Start building with Reward Sciences

$100 in credits. No card required. Connect in minutes.