Overview Architecture Flexible data model Real-time engine Security & data control
All features Missions Recurring missions Streaks Collections Rules engine Points & loyalty Rewards & catalog Marketplace Segmentation
All solutions Customer activation Customer retention Customer reactivation Loyalty programs VIP engagement Personalized campaigns
All industries iGaming E-commerce Crypto Games Fintech Food Delivery Fitness Streaming Travel Mobility EdTech Telecom
About Contact FAQ Use cases
Why us Easy integration
Developers
Talk to sales
Architecture

Your servers call ours. There is nothing to install.

Every connection starts on your side, as an ordinary outgoing HTTPS request. We hold no login to your database, put no software on your servers, and take no copy of your data. You send us what a customer did, and read missions, streaks, points and the shop back out.

Security & data control
Start to finish

A customer buys something. Here is every step until the reward reaches them.

A customer pays for an order. Your server sends us one message. We add the amount to their running total, check it against your missions and streaks, and work out what they earned. We then call a web address you gave us and tell you what they won. Your app decides what happens next: a badge, a push, or the free delivery.

request path
How one customer action becomes a reward Your app tells Gemifier that a customer did something. Gemifier checks it against the rules your team set up and works out what the customer earned. calls a web address you gave it, usually within seconds and your app decides what to do with it: light up a badge, send a push notification, or hand over the reward. Your team builds the missions and rewards in the dashboard. Your database is never touched and never copied. Your app a customer buys, logs in or finishes a lesson you tell us Gemifier checks it against the rules your team set up works out what the customer earned, and remembers it we tell you back Then your app acts light up the badge, send the push, hand over the free coffee we call a web address you gave us, usually within seconds Your team builds the missions and rewards in the dashboard, without code Your database never touched, never copied, no login of yours held here no route from here into any of it
Which way the calls travel is the security model. We hold no login to your network and no password of yours. Your side always dials out to a public address. The only route back towards you is a web address you publish yourself and can switch off at any time.
Two ways in

Your code uses the API. Your staff use the dashboard.

Two separate entrances with two different kinds of login. Your servers authenticate with an API key. Your colleagues sign in with an email and password. Neither one can be used in place of the other.

your product

Public API

your live traffic

This is what your code talks to. You send two kinds of message: something a customer did, such as a purchase, and something that changed about them, such as moving up a tier. You read back their missions, streak, points balance and the shop as JSON. A key works in one environment only.

your team

The dashboard

people, signing in as themselves

This is the site your own staff sign in to with an email and password. They name the data you track, build missions, streaks and shop items, and read the reports. You create the roles yourself, so someone in marketing can build campaigns while someone in finance can only read the numbers.

Test and live

A test campaign can never pay a real customer.

Every account comes with two separate environments: Sandbox for testing, Live for real customers. They hold different customers, different campaigns and different points, and nothing moves between them. Which one you reach is decided by the key you send, not by a setting someone can tick by mistake.

  • Separate customers, missions, streaks, points and keys on each side. A test campaign cannot pay a real person.
  • The key decides which side you reach, so nobody reaches real customers by mistyping a setting.
  • A Sandbox key is refused by Live, so a leaked test key reaches no real customer.
  • Create a campaign in both environments, rehearse it in Sandbox, then switch it on in Live.
How keys are stored
project · environments
One project, two sealed environments A project splits into exactly two environments, Sandbox and Live. Each holds its own customers, missions, streaks, points and purchases, and each has its own keys. A dashed divider between them marks that nothing crosses. Project one product or brand no crossover Sandbox gem_sbox_… own customers, missions, streaks, points and purchases build and rehearse here Live gem_live_… the same objects, its own data and its own keys the key decides, not the body
Unguessable by design 256 bits of randomness
Never stored in plain text kept only as a one-way hash
Shown once, revocable any time bound to one environment for life

Send this page to your engineers.

On a call we will walk them through the exact request, how the test and live environments are kept apart, and what happens when a request fails halfway through.

Contact sales