From an Email to a Real Conversation: How TEEI Builds on Resend

A sign-in link. A reminder in the right time zone. A place in a class. The report after the conversation. Inside the email systems behind TEEI’s free learning programmes.

A place opens in a Skills Academy class. Someone on the waiting list moves into it. The email our platform prepares tells them they have a place, when the session happens and where to join. It asks for nothing more: no purchase, no second application, no race for the seat. If they are unable to come, it explains how to release the place for someone else.

That is one of the jobs email does at TEEI.

TEEI is a nonprofit providing free language practice, professional mentoring and skills opportunities. Our programmes serve Ukrainians affected by the war, including people still in Ukraine, and women from Latin America and Afghanistan. Volunteers bring their time, experience and subjects they know. Companies and community organisations help people take part.

For us, email is part of how the work is delivered as well as how it is announced. A person needs to get into their account, know whether a request was accepted, find a changed meeting time or hear that their access is ready. Resend carries the message at each of those points; our applications decide what it means and what the person can do next.

This note follows that relationship across our programmes and into the engineering underneath: programme-aware messages in six languages, recipient preferences, delivery receipts that come back into the product, and the retry design that keeps a repeated attempt the same email. That retry design is the part we most want other teams building on Resend to read.

In numbers

Source: TEEI’s public impact counter (/api/impact-stats.json), read 3 November 2026 at 10:13 UTC, and a read-only query on the nightly copy of the programme application’s email log, exported 30 October 2026 at 02:30:57 UTC.

One invitation, then a person on the other side

A manager opens Evenhall, TEEI’s workspace for partner companies, and invites colleagues to volunteer. The invitation arrives by email. An employee accepts, creates a programme account and makes time available. A learner can then book a conversation.

The invitation is the beginning of a route to something neither the email nor the company can do alone: two people meeting, with a reason to talk and time set aside for one another.

In TEEI Language, the volunteer is a conversation partner. In TEEI Mentorship, the person brings professional experience to a mentee’s question. Skills Academy gives volunteers a way to teach workshops, clinics, expert Q&As and classes across subjects. People combine these programmes according to their needs, in whatever order suits them.

When a session is ready to begin, the destination is a TEEI room. The person checks their camera and microphone in a lobby, then joins. The application runs on Cloudflare; the live conversation runs on Amazon Chime SDK. Resend’s job in this part of the journey is the communication around the meeting: the confirmation, the reminder, the changed time. The call and the attendance record belong to the room.

Heidi B., a volunteer language partner, describes preparing a topic and meeting her learners regularly. Her film shows the human work the platform exists to support: the conversation every one of these emails leads towards.

What the emails are for

TEEI’s email runs through three applications: the programme application behind TEEI Language, TEEI Mentorship and Skills Academy; Evenhall, the workspace for companies and Network Partners; and the public website. Each has its own send path, and Resend delivers for all three.

The range is clearest from the recipient’s side.

Underneath that table sit precise inventories. The programme application names 124 email events, and each one belongs to one of 39 communication topics, from account security to booking confirmations and learning resources. Evenhall has 25 email template identifiers: eight for company applications, two for demo requests, three for programme campaigns, one for scheduled report delivery, and others for employee and manager invitations, manager sign-in, support, volunteer time off, surveys, recognition and Skills Academy class requests. Its queue consumer handles eight outbox families. The programme application also holds 18 programme campaigns, each with steps that run from the first send to day 30.

The message is often small because the decision has already happened in the application. A booking has been accepted. A class place has opened. An organisation’s registration has entered review. The email carries that state accurately to a person and points to the one action that follows.

For a small team, the breadth matters. The same organisation communicates with learners, volunteers, instructors, mentors, company managers and community partners. A useful email system gives each of them the message that fits their relationship with the programme.

One delivery service, every programme in its own voice

Language practice and career mentoring share substantial infrastructure, and each keeps its own identity.

Our programme email code takes the stored programme as the authority for every message. A mentee receives Mentorship email; a language learner receives Language email. The hostname or an internal role has no say in it. Skills Academy has its own email identity even where it shares account and delivery infrastructure with Mentorship.

This reaches well beyond the header. A reminder names the right activity. An acceptance describes the right relationship. A button returns the reader to the right programme surface. Sharing the transport removes duplicated engineering and keeps the product the person joined.

The same principle applies to status. Network Partners has separate templates for a registration received and access approved. The first says the registration is waiting for review. The second opens the organisation’s workspace. The welcome always matches the state the organisation is in.

Every template in the programme and organisational flows reviewed here produces a plain-text version alongside the HTML. The important information, the state, the time and the next action, reads the same in any mail client, designed card or plain text.

Language is part of the same care. TEEI Language’s localised emails render in six languages: English, Norwegian, Polish, Ukrainian, Spanish and Brazilian Portuguese, chosen from the recipient’s stored preference with English as the fallback. Skills Academy lifecycle email runs in English and Ukrainian, and programme digests in English, Ukrainian, Spanish and Portuguese. Mentorship, Evenhall and Network Partners email is written in English. The optional-email footer, with its unsubscribe link, follows the recipient’s language.

The time in the email is the time in the room

For a learner and a volunteer in different countries, “tomorrow at six” is too vague.

Our one-to-one email formatter starts with the booked instant and the recipient’s stored time zone. It adds the other person’s local time when that information is known, and leaves the line out when it is unknown, so every time in the message is a fact.

The booking-range formatter states the end time and the duration as well. A volunteer sees exactly how long they have agreed to stay without opening another page.

There is a smaller detail in reminders that is easy to miss. A scheduled job runs close to the nominal reminder time, sometimes a little after it. Our formatter calculates the remaining time from the actual difference between the session’s start and the current moment. A session forty minutes away is described as forty minutes away, whatever the job is called.

The calendar travels with the message. Booking confirmations and reminders carry Google Calendar and Outlook links built from the same booked instant. A Skills Academy registration arrives with a skills-academy.ics file. Meeting invitations and cancellations carry calendar attachments, and a subscription feed lets a person follow their sessions in their own calendar app.

These decisions belong in the application before the request reaches Resend. Resend delivers the message we send; describing the booking correctly is our job.

The class messages apply the same care to what a person does next. A Skills Academy waitlist-promotion message says the person is already registered. A reminder links to the session page and explains that leaving releases the place. The missed-session template is written as a welcome back: it invites the person to the next session and carries no penalty or deadline.

Resend’s place in the architecture

Each of TEEI’s three applications reaches Resend along its own path, built for the work it does.

The programme application sends through one central server module. Before it calls Resend, it writes a send intent to its email log, and every send carries tags for the programme and the intent, so a provider event can be matched to the exact row that caused it.

Evenhall sends through an outbox and Cloudflare Queues. Its production email queue delivers in batches of up to ten, retries a message up to eight times, runs at most two consumers at once, and passes anything that exhausts its retries to a dead-letter queue. Evenhall tags each send with its source, type, template, outbox row and environment.

Tags taught us a lesson of their own. Resend accepts a defined character set in tag values. On 10 September 2026 we measured that an outbox ID carrying a colon had been stopping every partner-application email, so applicants were unable to verify their address. Every Evenhall tag now passes through a sanitiser before it reaches Resend, and the code carries a comment with the date and the cause.

The public website has its own email helpers for enquiry notifications and donation receipts.

Programme campaigns follow a path of their own. Resend offers Broadcasts, with Contacts, Segments and Topics, for marketing email. TEEI’s programme campaigns run on our own campaign Worker instead, because each step is tied to programme records: a campaign is approved per campaign, environment, step and template hash, with a cap on volume. A one-time send token authorises the send, the campaign has to be armed in three independent places, and every touch reaches Resend through the same send API with its own idempotency key.

The boundary is clear. TEEI determines the recipient, programme, permission, message and destination. Resend accepts the send request and supplies the message ID and events our systems reconcile with their own records.

In Evenhall, the provider wrapper accepts HTML, text, reply-to details, tags and supported attachments. It passes an idempotency key and checks the SDK result before it reports acceptance: an accepted send is one with no error and a Resend message ID. We return to that check below, where it matters most.

An email obligation outlives the request that created it

Sending an invitation involves more than an API call. The application changes a record, schedules work and hands a message to a provider. One database transaction covers the first of those, and each of the others needs its own guarantee.

For Evenhall’s demo-request flow, we write the lead, the form submission and the email-outbox entries in a single database transaction. After it commits, we publish references to the outbox rows. The queue message itself is three fields: its kind, the outbox row’s ID and a version number. The recipient and the message content stay in the database, and the consumer resolves the work from there.

Other families have their own recovery shape. The employee-invitation flow writes the invitation and its outbox row separately, and we describe the single-transaction guarantee for the flows that have it.

On the queue side, a consumer has to win a conditional database update before it proceeds. A row with a recorded Resend message ID leaves the claim path for good. A lease lets interrupted work become eligible again.

The programme application keeps the same discipline in its own log. Each send intent takes a five-minute lease. Its idempotency key is the caller’s own domain key, or email-auto: followed by a SHA-256 hash of the recipient, the event and the exact rendered bytes, so the key itself carries no address or content. A ledger write that meets a busy database retries after one, two, four, eight and sixteen seconds. A single email gets at most six provider calls inside a 20-hour boundary, and a transport failure with an unknown result is held for Resend alone (held:resend) until Resend’s own answer settles it.

An expired lease says the consumer stopped. It says nothing about the provider: the first consumer may have stopped after Resend accepted its request. That is where Resend’s idempotency support comes in, and where our first design missed something.

The retry sends the same email

We gave every email a stable idempotency key from the start. The question we had missed was whether a later attempt would carry the same content.

Picture a send that Resend accepts, with the response lost on its way back to our application. The row becomes eligible for retry. Between the two attempts, we deploy a revised email layout. A retry that renders the template again presents different content under the old key. A fresh timestamp or token in the template does the same, with no deployment at all.

Resend’s idempotency documentation is exact about what happens next. Resend keeps an Idempotency-Key for 24 hours. The same key with the same payload returns the original response, and the email goes out once. The same key with a different payload returns a 409 with invalid_idempotent_request. A second request while the first is still in progress returns a 409 with concurrent_idempotent_requests. Resend’s engineering team makes the same point in Engineering Idempotency Keys: a retry is a retry when it carries the same key and the same payload inside the window. Resend recommends keys shaped as <event-type>/<entity-id>.

These are clear, useful semantics. Our application’s job is to keep the request they apply to.

Evenhall does that by freezing the first attempt. Before the first send, it stores the provider-relevant message fields: the sender, subject, reply-to address, HTML, text, tags and a supported attachment. Every later attempt replays those stored fields when the payload store is available. A deploy changes the template for the next invitation and leaves an invitation already in retry exactly as it was first sent. The recipient, the key and the audience come from the prepared message and its outbox context, and the recipient authorisation check runs before every attempt, replayed or fresh.

The fix landed for report emails on the morning of 29 September 2026, and for invitations, demo requests, applications and campaigns two hours later.

The acceptance decision is just as strict. Here is the decision in the wrapper, with names retained and surrounding code omitted:

// Excerpt: after resend.emails.send(...).
if (result.error) return classifyProviderError(result.error);
if (!result.data?.id) {
  return {
    kind: "rejected",
    errorCode: "provider_message_id_missing",
    retryable: true,
  };
}
return { kind: "accepted", providerMessageId: result.data.id };

Source: TEEI, Evenhall’s Resend provider implementation, reviewed on 30 October 2026. The Network Partners sender applies the same check on the error and the message ID.

Three rules follow from those lines. A send counts as accepted only with a Resend message ID, and that ID goes onto the outbox row. A response without an ID is a retryable rejection, so the next attempt replays the frozen fields under the same key. Every provider error goes through one classifier, which sorts it into a known branch.

The branches are explicit. A 409 with concurrent_idempotent_requests means another request with the key is still in progress, and we retry. A 429, any 5xx, a transport failure and an answer without a message ID are retryable. A 409 with invalid_idempotent_request proves that an earlier request with this key reached Resend, so we record the row as dead_letter with unknown_outcome. A person checks that row before anyone sends a replacement, and the recipient receives one invitation, as intended.

The model tests run sequential retries across a layout change and check that every later attempt reuses the first message fields. Company report emails follow the shape Resend recommends: each recipient’s send carries a key built from the delivery, its revision, the recipient and the template version, csr-report/<delivery>/<revision>/<recipient>/v<version>.

This is the most useful engineering lesson we can offer another team building on Resend: give the email a stable identity, keep the content that identity refers to, and keep an exact account of what you know about each attempt.

A receipt comes back into the product

The send response opens the record. The receipt completes it.

Resend signs its webhooks with Svix. In the programme application, the Resend webhook endpoint verifies the signature against the raw request body before it parses the JSON. It then writes the event into a durable inbox where the svix-id is the primary key, and an insert for a known ID does nothing. Resend keeps the same svix-id when it delivers an event again, so a repeated webhook lands on the row that already exists and produces no second side effect.

Each event ends in one of four outcomes: processed, unmatched, ignored or a processing error. A processing error answers with a 503, and Resend delivers the event again. An event that arrives before its send-log row is matched once the row exists, so an early complaint still leads to a suppression decision.

A reconciliation pass runs on the programme application’s 15-minute schedule. It asks Resend directly about sends that are still waiting for an event, each row at most every six hours, over a 35-day lookback, and marks a send unknown after 30 days without an answer.

The event processor reads Resend’s own categories. Resend’s event definitions separate email.sent, an accepted send request, from email.delivered, a handover to the recipient’s mail server. Bounces arrive as Permanent, Transient or Undetermined. TEEI suppresses an address on a Permanent bounce. Transient and Undetermined bounces are recorded against the send. When a receiving server refuses one message’s content, TEEI records that against the message and keeps the person’s address open. A complaint moves the address out of marketing email.

Those distinctions matter because email is also the way into an account. An accurate delivery decision keeps a person’s route back into a programme open. Provider events become useful when the application reads them in the context of the service.

Evenhall verifies its webhooks with the Resend SDK and stores delivery events in its own table, matched by message ID. Every Evenhall send carries an environment tag, so each event is traced to the deployment that sent it.

Here is the week we measured for this note:

Source: TEEI, programme-application email log, read-only query on the nightly copy exported 30 October 2026 at 02:30:57 UTC.

Our previous measurement, for the seven days to 17 October 2026, recorded 4,077 sends and 4,054 receipts. Two weeks later the volume has more than doubled, and the delivered share holds at 99.4%.

Delivery evidence answers a delivery question. Participation has its own evidence, recorded in the room.

The programme’s own records measure the next step

Open and click tracking on TEEI’s main sending domain have been off since 26 August 2026, by decision. Resend sets tracking per domain, and click tracking rewrites every link through a tracking subdomain. Several TEEI emails carry single-use claim and sign-in links. With tracking off, those links reach the person exactly as we wrote them, never rewritten through a click-tracking redirect. Resend’s tracking guidance itself discourages the open pixel for transactional email.

The decision is recorded in our repository, alongside a read-only script that checks the domain’s tracking settings and webhook subscriptions against the Resend API.

The consequence is visible and expected. On 3 September 2026, 1,533 DataCamp invitations showed zero opens. The same day, the programme’s own records showed 99 of those people on the claim page and 62 completed claims. The open column stays at zero by design; the claim is the number that counts.

For a learning-resource invitation, the meaningful next event is a completed claim. For a session, it is a booking followed by time in the room. Those events belong to the applications, and each is measured where it happens.

Resend receives the address and the message we ask it to deliver. Our aim is precise: collect only the engagement data the programme uses, and answer engagement questions from the programme’s own records.

The same principle shapes what we keep during retries. Evenhall’s frozen message contains personal content, so the implementation deletes the stored payload once no further attempt needs it, with a cleanup for rows settled through other paths. We keep what a send needs for reconciliation, for as long as it needs it.

The right channel for each moment

A platform with many events could produce many messages. Ours sends the ones that help.

Our communication-topic catalogue separates email, in-app and device notifications. The controls people see are organised around what they recognise, bookings, reminders, programme updates, progress and support, in place of provider terminology.

Some events live entirely outside the inbox. The community-room conversation is an in-app notification. Live-availability and practice-table alerts use other channels. Each event gets the channel that fits it.

Optional communication and necessary account or session communication follow different rules. Suppression and delivery blocks take precedence over a preference. Every email event has to be assigned to a topic before it can be sent; adding a template is only the first step.

That gate is in daily use. In the seven days we measured, the programme application held back 299 sends under its suppression rules, 92 events still waiting for a topic and 14 sends for a programme whose sending was switched off, all before any call to Resend. Optional programme email carries a one-click List-Unsubscribe header, so a mail client’s own unsubscribe button works.

For Resend, this means every request that reaches the API is intentional: a particular message, for a particular person, for a reason the programme can explain. The value lies in making each call useful.

The relationship continues after the invitation

Companies need to know what happened after their colleagues signed up. Community organisations need a way to introduce people to learning opportunities without building a learning platform of their own.

TEEI Network Partners is that second route. Organisations bring learners, members, staff or volunteers into the same programmes. Their Network Workspace has five email templates of its own, among them registration received, access ready, a colleague invited and a requested report available, along with sign-in by verification code and account recovery. These are messages about an ongoing working relationship.

The notice that a requested report is ready goes out once. It spends a single-use dispatch token, and any second trigger finds the token already used.

The architecture scales by sharing programme infrastructure while keeping the meaning and access boundaries of each organisation’s workspace. Evenhall’s provider boundary includes a recipient-authorisation check, so each organisation’s automated messages reach only the people that organisation has the authority to contact.

At the other end of the journey, company report emails go through Evenhall’s report-delivery outbox. The figures are frozen when the delivery is queued, so every recipient receives the same report. The templates carry a defined reporting period, a route back to the workspace and, where supplied, an attached report. The rendering code distinguishes data that was measured from data that was never computed, and shows an absent measurement as absent.

The participation record lives apart from the email record. For a one-to-one conversation, TEEI’s hours come from the time both people were connected to the room, rather than the duration written in the calendar invitation. “Verified” means verified by TEEI from its room records.

The company sees its employees’ contributions, and the learning conversation stays private. Volunteer hours come from the room; delivery receipts stay in the email record.

What building on Resend lets us concentrate on

Resend gives our applications a delivery API, a message ID for every send, documented retry semantics and signed events we bring back into our own records. We build on those pieces every day.

They let us spend our attention on the decisions that belong to TEEI. Does this person need the message? Does it describe the actual state of their booking or application? Will it take them to the right place? Can the organisation understand what happened while the private parts stay private?

That makes useful provider interfaces especially important. We need capabilities we can build into a larger service, inspect when something goes wrong and explain to the people who depend on us. The Resend integration is one part of that service, alongside our own programme software, Cloudflare’s application infrastructure and AWS’s meeting services.

The volunteer brings the conversation. The mentor brings their experience. The learner does the learning. Email gets each of them to the right place at the right time.

Its contribution is quiet and very concrete: the invitation that can be acted on, the changed time someone can check, the class place someone learns is theirs, and the record that comes afterwards.

That is what we are building with Resend: part of the infrastructure that helps people take an opportunity, from the first invitation to the record afterwards.

What comes next

Network Partners will be able to invite their own members from the workspace’s sharing tool. It sends through Resend’s batch endpoint, every message carries a one-click List-Unsubscribe header, and its tags identify the partner and the send without carrying an address. The tool is built; connecting its delivery webhook and switching it on are what remain.

About the evidence

This note draws on a review of TEEI’s repositories on 30 October 2026, covering the programme application, Evenhall and the website, and on our earlier engineering articles. Code shows implemented behaviour; optional messages, translations and report schedules run where each programme has switched them on.

The email figures come from a read-only query on the nightly copy of the programme application’s database, exported 30 October 2026 at 02:30:57 UTC, over the seven days before. They cover that application’s Resend sends. Evenhall recorded 18 sends with a Resend message ID in the same window, and the website and incoming support mail keep their own records. A delivery receipt means Resend handed the email to the recipient’s mail server.

Conversations, hours and countries come from TEEI’s public impact counter, read on 3 November 2026 at 10:13 UTC. Verified hours are verified by TEEI from its own room records.

The freeze-and-replay design covers Evenhall’s outbox families where the payload store is available, with one attachment per message, and its model tests run sequential retries across a layout change. The programme application also contains provider-policy and fallback code; the examples here follow its Resend path.

The volunteer film is Heidi B.’s consented story. This note attributes no attendance, learning or employment outcome to email; the programmes measure those outcomes in their own records.

For the narrower technical accounts, see our email-outbox implementation, the meeting-to-hours record, the Cloudflare platform architecture and the Project Galileo story. Provider semantics are documented in Resend’s idempotency reference and webhook event reference.