Question 1

Do you need access to our database?

Accepted Answer

No, and there is no mechanism by which we could. Gemifier ships no database client for your systems, no replication process, no agent to install and no route into your private network. Traffic starts on your side: your backend posts activity to the Gemifier ingest endpoint and reads state back out, authenticated with a key you mint and can revoke. The only thing Gemifier ever starts is a webhook, and only to a public URL you chose to register.

Question 2

What personal data does Gemifier store about our customers?

Accepted Answer

A customer record holds your own identifier for them, an optional time zone, and timestamps. There is no field for a name, email address, phone number, address or document. Beyond that you decide: customer attributes are declared by you and typed as String, Number, Boolean or DateTime, so personal data has nowhere to go unless someone on your side deliberately creates somewhere for it to go.

Question 3

Is Gemifier GDPR compliant or certified?

Accepted Answer

We make no certification claims. Gemifier is not SOC 2, ISO 27001 or PCI certified, and GDPR compliance is not a badge anyone can hand you. The statement we can make as fact is architectural, and it is usually what a data protection officer cares about: the customer record has no PII fields, so what we hold is your opaque identifier plus counters and timestamps. You remain the controller and we only hold what your backend chose to send.

Question 4

Where does our data live and how is it separated from other customers?

Accepted Answer

One Postgres database with an isolated schema per organization. The schema is pinned on every connection and its name is derived from an internal identifier as 32 hexadecimal characters, never from user input. A connection that arrives without a resolved tenant is refused rather than defaulted. There is no dedicated database per customer, no customer-managed encryption keys and no choice of region.

Question 5

Can we send events to Gemifier in bulk?

Accepted Answer

No. It is one message per thing that happened, checked against your own model as it arrives, so a wrong key fails loudly instead of disappearing into a half-accepted batch. In practice it constrains less than it sounds: requests can be sent concurrently, though two for the same customer and metric can collide and ask you to retry, and sending the same thing twice is safe when you attach an idempotency key.

Question 6

What happens if we send the same event twice?

Accepted Answer

If you attach an idempotency key, the second request returns the result of the first instead of counting the purchase twice or charging the customer twice. Without a key, a second request is a second event, because there is no way to distinguish a duplicate from a customer who genuinely did the same thing again.

Question 7

Can our customers read their progress through the Gemifier API?

Accepted Answer

Yes. Two endpoints send activity in; ten more read state back out so you can build the screen your customers look at: their mission feed, a curated collection, opting into a mission, streaks, the points balance, the points ledger, manual adjustments, the shop, a curated shop section, and buying an item. What you get from us is the data behind the screen. The design, the animation and the copy are yours, on your release train.

Question 8

How do we find out when a customer has earned something?

Accepted Answer

Register an HTTPS endpoint and Gemifier posts each reward grant to it as it happens, so your fulfilment code has a trigger rather than a polling job. Every delivery is signed with HMAC-SHA256 so you can prove it came from us, the signing secret can be rotated, and you can send a test delivery and read back the status your endpoint returned. Outstanding deliveries are visible and abandoned ones can be retried by hand. Register nothing and the grants are still recorded: you read them instead of being told.

Question 9

Does Gemifier report on how a programme is performing?

Accepted Answer

Yes, in the dashboard. Daily, weekly and monthly active players; the mission funnel from occurrences seen to opt-ins to completions; points in and out by day split by what caused the movement; how many customers are on a streak right now; how streak runs ended and at what length; and marketplace sales in units and points. Per environment, one at a time. It is not a substitute for your BI stack, which is where revenue lives, but it answers whether a mechanic is working without an export.

Question 10

Do streaks have grace periods, freezes or a skip day?

Accepted Answer

No. One missed day restarts the run at 1, and that is deliberate. Two things soften it in practice: a streak is endless, so there is no finish line to fall off, and the longest run a customer has ever reached is kept permanently as a high-water mark. Multiple qualifying events on the same day count once.

Question 11

How do time zones decide when a day ends?

Accepted Answer

A day boundary is local midnight in the customer's resolved zone. You can send a time zone with an event, in which case that person's daily missions and streak days follow their own calendar; the environment default applies, which is the zone the project was created with. A mission or streak can instead force the project default so everyone rolls over together. Week start is configurable to any of the seven days and defaults to Monday.

Question 12

How does Gemifier handle multiple currencies?

Accepted Answer

Each environment has one base currency, fixed at creation and immutable afterwards. Currency events arrive in the currency the customer actually transacted in with the exchange rate you supply, and are normalised into the base currency for rule evaluation. The original amount, the original currency and the rate used are all preserved. Rates are time-versioned and immutable, so an event is converted at the rate in effect when it occurred. There is no live FX feed.

Question 13

Do you support SSO and MFA?

Accepted Answer

Not today. Dashboard sign-in is email and password against a signed access token. There is no SAML, no OIDC, no social login and no second factor. Dashboard access is people-only and separate from ingest, where machines authenticate with project API keys on a different host, and permissions are granular enough that most accounts can be given no authority to change anything that matters.

Question 14

How are API keys stored, and how do we rotate one?

Accepted Answer

A key carries 256 bits of entropy and a readable prefix, gem_live_ or gem_sbox_, so a leaked key is recognisable in a log. Only its SHA-256 hash is stored and comparison is constant time, so the full key is shown once at creation and cannot be recovered afterwards. Rotation is create-then-revoke: mint a second key for the same environment, deploy it, then revoke the old one. There is no expiry date and no per-key scoping; a key is bound to one environment and that is the whole of its authority.

Question 15

Is there an audit log?

Accepted Answer

Not a user-facing one today. Configuration changes are not exposed as a browsable history. What is immutable is the record of what happened to customers: the points ledger is append-only with Grant and Spend transactions, exchange rates are versioned rather than overwritten, and every reward grant keeps its source, whether that was a mission, a streak or a marketplace purchase.

Question 16

What happens when a reward fails to process?

Accepted Answer

It is retried automatically and repeatedly, with a widening gap between attempts, over roughly the following half hour. Nothing is dropped quietly and nothing retries forever: work that keeps failing stops in a failed state somebody can see, and outstanding reward deliveries can be put back in the queue by hand. Every grant carries its own status of Pending, Granted or Failed, so whether a customer actually received something is a question with an answer rather than a guess.

Question 17

Does Gemifier fulfil the rewards themselves?

Accepted Answer

No. Points are internal and settle against the customer's balance as an append-only ledger entry, and a balance can never go negative. Anything real, such as a discount code, a free month or free spins, is a catalog item with a typed value; when a customer earns or buys one, Gemifier records a grant against it and your platform fulfils it. Gemifier never holds money, never moves money and never issues the reward itself.

Question 18

Can we A/B test campaigns in Gemifier?

Accepted Answer

Not as a built-in experiment. There is no variant assignment, no significance testing and no results screen. What you can do is split the population deterministically: set an attribute on your side, put it in the eligibility condition of two otherwise identical missions, and each customer becomes eligible for exactly one of them. The mission funnel then shows each arm separately. Deciding which one won against revenue happens in your own BI stack.

Questions we get, answered without marketing language.

The answers that settle most of the meeting.

What engineers and data protection teams ask first.

What exists today, and what does not.

Ask us the one we did not answer.