Email & SMS platform
OrnexReach is the email and SMS platform for teams whose customer data lives in more than one system — and whose consent record has to hold up when somebody asks.
Illustrative interface. Figures are examples, not benchmarks.
Why we built OrnexReach
An unsubscribe lands in the email tool, the CRM keeps its own tick-box, and a spreadsheet import quietly re-opts somebody in. When a complaint arrives, nobody can say which record was true at the moment of sending.
Two email addresses, an old phone number, a CRM id and a CSV row. Without one canonical person behind them, segments are guesswork and the same customer gets the same campaign twice.
A reminder that should take an afternoon takes a sprint, because the event, the template and the rule all live in code. Marketing waits; the backlog wins.
What OrnexReach does
Six things it takes care of, so the campaign is the only thing you have to think about.
A canonical profile with an identity graph behind it, so email addresses, phone numbers and external ids all resolve to the same customer.
An append-only ledger — nothing is ever updated or deleted — projected into a live consent state using most-restrictive-wins.
Amazon SES v2 for email and AWS End User Messaging for SMS, behind a single send API with idempotency and a contract-locked response.
Drag-and-drop blocks that render Outlook-safe HTML, with brand themes applied at creation time and reusable saved sections.
Bring customer data in the way you already have it, map it once, and preview the diff before anything is written.
Register an event, point a rule at it, pick a template. No deploy, no developer, and a test-fire before it ever reaches a customer.
How it works
Upload a CSV, point a webhook at us, or pull from Salesforce or OrnexCRM. Map columns once; the mapping is versioned.
Every inbound signal is written to the ledger. The current state is derived, never overwritten, and always shows its working.
Compose in the builder on your brand theme, or reuse a saved section. Preview, send a test, then activate.
Attach a trigger rule or a segment, watch delivery events land, and export the numbers when finance asks.
Under the hood
The things you only notice when they're missing — and the reason a send you scheduled last month still behaves the way you expect.
Every workspace-scoped read is filtered by workspace, and a cross-tenant lookup returns a 404 rather than a 403 — so existence itself isn't leaked.
Durable idempotency keys in Postgres mean a retried request doesn't become a second email to the same customer.
Separate SQS lanes for marketing, transactional and ingestion traffic, each with a dead-letter queue, so one noisy campaign can't starve a password reset.
Schema changes are additive and nullable-safe, and the send API response shape is pinned by a test. Upgrades don't break your integration.
Media is content-addressed and served through a CDN, and any asset used in a sent email is frozen — the URL in a two-year-old email still resolves.
Rule activations, mapping changes, consent overrides and key rotations are recorded with who did them and when.
Runs in AWS eu-west-2 (London), with sending, storage and processing kept in region.
A scheduled job reconciles our record of what was sent against what the providers report, so the reporting you export is the reporting that happened.
Consent & deliverability
Consent isn't a checkbox on a campaign screen. It's enforced twice — when a send is created and again at the moment it fires — and there is no code path around it.
A later opt-out always beats an earlier opt-in for the same identifier and purpose. Re-importing an old list can't resurrect a lapsed permission.
A marketing send whose body has no unsubscribe link is rejected at the API, not caught in review.
Transactional messages ride their own queues and are counted separately — and a marketing template can't be sent as transactional to dodge the gate.
Customer story — placeholder
Name, Role — Company
Common questions
The gating item is almost always domain authentication — SPF, DKIM and DMARC records have to be published and verified before anything leaves. Once DNS has propagated, importing a list, building a template and sending a test is same-day work.
No. OrnexReach sits alongside whatever you already run. Data comes in by CSV, REST, signed webhook or a scheduled pull, and unsubscribes can be read back out through a consent feed so your CRM stays current.
OrnexReach is, by design. Inbound connectors can revoke consent but never grant it, so an import can't quietly re-subscribe somebody. Your other systems can poll the consent feed to stay aligned.
In AWS eu-west-2 (London) — database, queues, media and sending infrastructure. Each tenant's data is isolated at the row level and enforced on every read.
Yes, that's the point of the self-service layer. An admin registers an event type, builds a rule against it in the portal, picks a template, and test-fires it as a dry run — with no deploy and no developer.
OrnexReach is an API first and a portal second. Sends, events, profiles and templates are all available over REST with scoped API keys, and the interactive reference is published with the service.
A 30-minute walkthrough: connect a sample list, build one journey, and look at what the consent ledger records. No slideware.