No database access, no login to your systems, no personal data required.
We have no login to your systems and no field to put a customer's name in. Most of what a security questionnaire asks about does not apply, because the thing it is asking about is not there to begin with.
We only store the ID your own system already uses for that person.
When you tell us a customer did something, you refer to them by whatever ID your own database uses, such as pl_8f2a41c. That string means nothing to us. Alongside it we keep their time zone, if you send one, and the dates the record was created and changed. That is the whole record: no field for a name, an email or a phone number.
// this is everything we store. there is no second page { // your own id for the customer. it means nothing to us "externalPlayerId": "pl_8f2a41c", // optional. only used to work out when their day ends "timeZoneId": "Europe/Lisbon", // when we first saw them, and when the record last changed "createdAtUtc": "2026-03-04T09:12:44Z", "updatedAtUtc": "2026-07-29T18:03:10Z" }
You can still put personal data here if you decide to
You define your own fields, and we do not police what goes in them. If you create one
called email and send email addresses into it, personal data is now stored
here. That is your decision to make, not something the product does on its own, and it is
worth knowing before you sign off a data map.
- Everything you declare is text, a number, a yes/no or a date
- Nothing is inferred, enriched or bought from a data broker
| We never ask for | Why it is not needed |
|---|---|
| Database credentials | Nothing here connects to your database. |
| Replication or exports | We never mirror your tables. There is no copy to leak. |
| Direct server access | No VPN, tunnel or SSH key. The only address we call is the webhook URL you give us. |
| Personal data | No field for a name, email or phone number. |
| Payment details | We never hold or move money. |
A leaked test key is refused by the live environment.
Your company's data is kept separate from every other company's, and every request is pinned to your company before a single query runs. A key that matches no company is refused. And a key belongs to one environment for life, so a test key leaked in a public repo still cannot touch a real customer.
- Unguessable. 32 random bytes, labelled
gem_live_…orgem_sbox_…. - Shown once. No endpoint returns the raw key again.
- Never stored in plain text. We keep a one-way hash. A lost key is revoked and reissued.
- A wrong key gives nothing away. A key is 256 random bits, looked up by the one-way hash we store, so a wrong guess narrows nothing down.
- Revocation fails safe. The key stops working the moment you press the button.
- Roles you build yourself. Permissions are granular enough that a role can match the actual job, such as building campaigns but not viewing the reports.
Bring your security questionnaire.
Send the document over before the call. We will fill in what applies, and mark the questions that do not apply here with the reason why.