IYS Consent Hub — bringing scattered consent data into one ledger
Built for Korendy: an integration that unifies commercial message consent held separately in Shopify, Klaviyo, in-store kiosks and İYS into a single, legally auditable consent ledger.
Why it was needed
Consent data lived in four separate places: Shopify on the e-commerce side, Klaviyo on the sending side, kiosks and a mini-site in physical stores, and İYS on the legal side. None of the four knew about the others.
The practical consequences were clear. Consent collected in a store never reached İYS, so it was legally invalid; and when a person opted out through İYS, that opt-out did not propagate to Shopify and Klaviyo, creating the risk of messaging without consent. No system could answer the question "what exactly did this person consent to, when, and under which wording?"
The regulation leaves no room here: consent not recorded in İYS is treated as invalid, and the burden of proof sits with the service provider even when a licensed integrator is used.
- One consent ledgerWhichever channel it arrives through, consent is written to the central ledger first; İYS, Shopify and Klaviyo are then fed from that ledger.
- No lost or duplicated consentThe state change and the outgoing queue record are written in the same database transaction, so consistency holds even if an intermediate step fails.
- Two-way synchronisationAn opt-out submitted through İYS propagates automatically to the systems that send messages.
- Mandatory OTP in storeIn-store consent requires one-time code verification, which prevents consent being recorded against the wrong number.
- Audit-ready historyEvery opt-in and opt-out is stored with its timestamp, its source and the exact wording shown, and can be reported with SQL.
Key technical decisions
Why PostgreSQL? The issue here is not volume but guarantees. A million customers across three channels is an ordinary load for a relational database. Consent, however, is a legal record: it needs uniqueness per recipient and channel, the state change and the queue write have to happen in the same transaction, and the full history must be reproducible during an audit. PostgreSQL gives all three naturally.
Why no separate queue infrastructure? The job queue lives in the same database. That leaves nothing extra to operate: one database, two processes.
Why a licensed integrator? İYS operations run through a licensed integrator, which removes unauthorised access and compliance risk from the outset.
Historic consent cannot be bulk-uploaded to İYS.
The İYS API rejects consent older than three business days, and the window for migrating historic data closed on 1 January 2021. In other words, "we will just bulk-upload the whole customer list" is not an option.
That finding changed the direction of the project: the first synchronisation was designed to read from İYS. Records that appear opted in on the sending systems but have no counterpart in İYS were separated out to go through a fresh consent flow.
Let's adapt this solution to your business.
Share your current infrastructure, your expectations and your budget range, and we will work out which part an existing product covers and which part needs custom development.