@volter/twin-resend
Resend
Local Resend transactional email, delivery events, domains and inbox inspection. Delivery is simulated; no real email is sent.
Publisher README included in @volter/twin-resend 1.0.1. Setup gives the installation instructions for this selected version.
A local Resend. Its API (api.resend.com) serves the calls Dub, Twenty, Postiz and Volter World's platform make: emails
sent singly and in batches and listed, sending domains (created, read, listed, updated, verified, removed), and received
emails and their list. Resend's webhooks go to a team's
endpoints, signed as svix signs them. The inbound CDN (inbound-cdn.resend.com) serves a received email's raw message.
Use with an existing app
In an app that already uses this vendor, install this exact release and the product CLI:
npm install --save-dev --save-exact @volter/world@3.0.67 @volter/twin-resend@1.0.1
npx volter world init --name my-app --twins resend --source resend=@volter/twin-resend
Review the detected vendor and generated bindings before booting. Read the credential names and limitations below; the World supplies throwaway credentials. Then run your app's own command through the World:
npx volter world up
npx volter world run -- npm test
npx volter world log
npx volter world down
Here npm test is your app's existing command; replace it with your app or test command. down retains state.
A later up resumes it; do not reset or initialize again merely to return.
Publisher and catalog contribution instructions: the public publisher guide.
A Protocol 3 pack (publisher guide). Its surface is generated
from Resend's OpenAPI document (spec/). Handlers
are in src/semantics/<family>.ts, the key front in src/semantics/around.ts, the lifecycle in
src/semantics/clock.ts, and state machines in src/semantics/states.ts.
world-resend serve [--port N] [--root DIR] [--read-only]
What it models
- Keys:
- A key is made on the API Keys page (a door) and held by its SHA-256.
- A request with none is
401 missing_api_key, an unknown one400, and a deleted one403 restricted_api_key. - Everything a key does is its team's.
- Sending:
from,to(at most 50),subjectand a body are required.- The sender must be at a verified domain of the team, or at
resend.devsending only to the team owner's address. - A batch of up to 100 is checked whole before any is sent.
- Attachment bytes are held in blobs and retained for inbox observation. Dub's ISO scheduled sends wait until their requested time before following the ordinary delivery lifecycle.
- An email's life:
queued, thensentat once. Five seconds later it isdelivered, orbouncedwhen a recipient's server refuses its domain's mail (a door). A recipient may then open it (on a domain with open tracking) or mark it as spam (doors). - Domains:
- Each has its DKIM, SPF MX and TXT, Tracking and Receiving records.
- Verifying makes it pending. It is verified ten minutes after the later of the verify and its last record at the owner's DNS host (a door), or failed after 72 hours without them.
- Updated: open and click tracking, TLS, the tracking subdomain and capabilities.
- Receiving: mail to a verified receiving domain (a door) is a received email, with attachment metadata and bytes retained, read with its pre-signed raw download URL, which lasts an hour.
- Webhooks:
- Sent for
email.sent,email.delivered,email.bounced,email.opened,email.complainedandemail.received. - Each goes to the team's endpoints that subscribe to it, signed with
svix-id,svix-timestampandsvix-signature.
- Sent for
Doors
POST /_twin/api-keys {name, team, owner}andDELETE /_twin/api-keys/{id}: the API Keys page.POST /_twin/webhooks {team, endpoint, events}: the Webhooks page; answers the signing secret.POST /_twin/dns {name, type, value}: a record at the owner's DNS host. Supply its fully qualified name: for a domainexample.com, returnedsendmeanssend.example.comandresend._domainkeymeansresend._domainkey.example.com; use the returned value unchanged.POST /_twin/recipients/{domain} {rejects}: an outside server that refuses mail.POST /_twin/mail/{email_id}/openand/complain{to}: a recipient's act.POST /_twin/inbound {from, to, subject, text?, html?, inReplyTo?, headers?, received_for?, authentication?, attachments?}: mail from outside to a receiving domain.GET /_twin/mail?to=: an inbox.GET /_twin/deliveries?to=[&type=][&email=]: the webhooks sent.
Not yet
Broadcasts, segments, topics, templates, suppressions, audiences and contacts, the API Keys and Webhooks APIs and contact properties: no application here calls them.
Vendor-backed
Lists are newest first, paged by limit, after and before. A refresh reads sent emails, received emails and domains back from their
lists and detail operations; Resend's signed email events are ingested (each folded into its email by email_id, its type the email's
last_event); calls are charged within a fixed allowance of 120 per minute, below the documented 600 per minute.
Set up this release
Use Node 22.6 or newer. Install the CLI, then the exact packages shown alongside:
npm install -g @volter/world@3.0.108In your app’s folder, initialize a World with this implementation:
volter world init --name my-app --twins resend --source resend=@volter/twin-resendReview the detected vendor and retain the generated bindings. The resend service’s source must select this version:
{
"source": {
"package": "@volter/twin-resend",
"version": "1.0.1"
}
}This is the source field, not a complete config. Keep the installed version, lockfile and generated service source in agreement. Use the release README for throwaway SDK credentials, seeds and limits.
Run your app’s own test command inside the World:
volter world up
volter world run -- npm test
volter world log
volter world downdown stops compute and retains state.
Versions and implementations
| Package / version | Publisher | Status | First use |
|---|---|---|---|
| @volter/twin-resend1.0.1 | volter-ai | Selected default | Not measured |
Evidence for 1.0.1
Installed first use · Not measured
Installed first use was not measured for this release. HTTP coverage and publisher trust do not establish this result.
API coverage, replay and browser measurements
Counts describe the declared HTTP surface, not separate command tables or other protocols. Consult the release README for those workflows.
- Assessment scope
- packaged-customer-journey; in-process
- Declared HTTP surface
- 12 served · 103 gaps · 115 declared operations
- Exercised HTTP operation coverage
- 11 / 115 declared operations (9.6%)
- Journey steps
- 55 answered / 73 steps
- Replay
- Equal across 2 runs
- Journey failures
- 0
- Browser target
- HTTP customer journey replay through Chromium at each request origin; authored HTTP headers and observed wire responses 153.0.8010.12
- HTTP operations exercised through Chromium
- 11 / 115 declared operations (9.6%)
- Chromium journey replay
- Equal across 2 runs
- Browser response observation
- Transport observes status, headers and body, including redirects and Set-Cookie; these are not JavaScript-visible response claims
- Application-origin CORS coverage
- Not measured
- Native cookie-jar coverage
- Not measured
- DOM coverage
- Not measured
- Source code coverage
- Not measured
- State transition coverage
- Not measured
Operations not exercised
resend:api-keys/createresend:api-keys/listresend:api-keys/removeresend:api-keys/updateresend:audiences/createresend:audiences/create-contactresend:audiences/getresend:audiences/listresend:audiences/removeresend:audiences/remove-contactresend:automations/createresend:automations/duplicateresend:automations/getresend:automations/get-runresend:automations/listresend:automations/list-runsresend:automations/removeresend:automations/stopresend:automations/updateresend:broadcasts/cancelresend:broadcasts/createresend:broadcasts/duplicateresend:broadcasts/getresend:broadcasts/listresend:broadcasts/list-clicked-linksresend:broadcasts/recipientsresend:broadcasts/removeresend:broadcasts/sendresend:broadcasts/updateresend:contact-properties/createresend:contact-properties/getresend:contact-properties/listresend:contact-properties/removeresend:contact-properties/updateresend:contacts/add-segmentresend:contacts/createresend:contacts/create-importresend:contacts/getresend:contacts/get-importresend:contacts/listresend:contacts/list-importsresend:contacts/list-segmentsresend:contacts/list-topicsresend:contacts/removeresend:contacts/remove-segmentresend:contacts/updateresend:contacts/update-topicsresend:domains/create-claimresend:domains/get-claimresend:domains/verify-claimresend:emails/cancelresend:emails/get-attachmentresend:emails/get-receiving-attachmentresend:emails/list-attachmentsresend:emails/list-receivingresend:emails/list-receiving-attachmentsresend:emails/metricsresend:emails/shareresend:emails/updateresend:events/createresend:events/getresend:events/listresend:events/removeresend:events/sendresend:events/updateresend:logs/getresend:logs/listresend:oauth/list-grantsresend:oauth/revoke-grantresend:segments/createresend:segments/getresend:segments/listresend:segments/list-contactsresend:segments/removeresend:segments/updateresend:suppressions/addresend:suppressions/batch-addresend:suppressions/batch-removeresend:suppressions/getresend:suppressions/listresend:suppressions/removeresend:templates/createresend:templates/duplicateresend:templates/getresend:templates/listresend:templates/publishresend:templates/removeresend:templates/updateresend:topics/createresend:topics/getresend:topics/listresend:topics/removeresend:topics/updateresend:usage/getresend:webhooks/createresend:webhooks/getresend:webhooks/get-eventresend:webhooks/listresend:webhooks/list-event-attemptsresend:webhooks/list-eventsresend:webhooks/removeresend:webhooks/replay-eventresend:webhooks/rotate-signing-secretresend:webhooks/update
Conformance results
- decided: 0 failures · every served operation is decided with its demand; every demanded and every refreshed operation is served
- published: 0 failures · what a release publishes holds every unit: its manifest, its spec and its journeys
- cited: 0 failures · every vendor fact cited is recorded as a page that answered, each quote found on it
- refresh: 0 failures · every stored resource of a vendor-backed unit declares how it is read back, and a unit that sends events ingests the vendor's
- registered: 0 failures · a vendor-backed unit, lane or not, reaches the registered pack's state system
- allowance: 0 failures · a rate budget above the fallback rests on the vendor's documented allowance, cited in its manifest
- client: 0 failures · driven by the vendor's own client (its official SDK), served as a World runs it, the vendor's documented behaviour holds · 3 case(s) through the vendor's client
- life: 0 failures · the life walked over HTTP against the pack served as a World runs it, with its scenario: every check held
- standalone: 0 failures · served by its server.ts as a World runs it, the pack answers HTTP and the boot probe, and each declared socket upgrades
Publisher, admission and provenance
- Publisher
- volter-ai/twin-packs-open
- Source commit
- dfe94d24ce480c148263f670a5026046cd7c3a40
- Catalog record commit
- 295e882725ec1faa30d138c9a10fd53e00e14d87
- Package integrity
sha512-rorxvx2YrMhmwB+bouDvfqY1ykbkWE4BDgjWFD6ZAFLmEwCsxxbcRy+lqGWo3hwQaCRMxdxP+KHn6bnIMlowcA==- Admission mode
- Trusted internal publisher · maintainer merge
- Catalog assessment
- Bundled report checksum verified
- Assessed at
- Not recorded
- Assessment input head
- 295e882725ec1faa30d138c9a10fd53e00e14d87
- Evidence
- Assessment and admission
Catalog snapshot · @volter/twin-catalog@0.2.41
- Source commit
a4c5e0664985a7f5a173b58cd307b88a7ddd2795- Catalog digest
5103e721dd9632a05ec4d5348d1b9e668ee092b3edf634c0e4b08f08efb76527- Installer integrity
sha512-uadY72Kz68IvyrNGcUCyJIOXAPQJz9dsyUgG7DUpTVFgZNseWyEQ1We/cSDi4Z9gPtd11owQAJ3EtAuIutcSQw==