Five products · live in production

Auth, Mail, Waitlist, Social and Trawl — five REST APIs behind one account, one API key and typed Node SDKs. Install the parts you keep rebuilding; build the part only you can.

Five products. One workspace.

Use one or all five. Each is its own REST API with its own docs, npm package and console pages; the account, the API key and the workspace are shared.

Pick the one that brought you here. The other four are already in your workspace.

Auth

Passkeys, tenants and MFA, without writing auth.

Sign in with Apple, Google or GitHub through a guided setup that checks your credentials as you save, and a bcrypt import so nobody resets a password.

The get-started page checks each step on the server, and Try sign-in runs a real sign-in against your app.

  • Tenants in the token. Org roles ride in the access token; each app signs with its own keys at /.well-known/jwks.json.
  • An audit log you can export. Every app keeps an append-only log, and webhooks replay from a 30-day event log.

Mail

Send from your domain, not ours.

Templates with a live preview as you edit, broadcasts to segments with one-click unsubscribe, and a delivery timeline for every message.

The live preview of a demo email after the edit: “Your autumn box is on its way, Ada.” Demo data.

Demo: Ada's autumn-box email, edited live.

  • A new broadcast in the console with a segment and a topic chosen, and its reach: 12 people would receive it now. Demo data; not saved and never sent.

    Broadcasts. Pick a segment or a topic, see how many people it will reach, then send now or on a schedule.

  • One email's record and its delivery timeline: queued, sent, delivered. Demo data, sent to the Amazon SES mailbox simulator; the recipient is cropped out.

    Proof it arrived. Every message keeps its delivery timeline; bounces feed the suppression list automatically.

  • A demo sending domain's DNS records: the DKIM key and the SPF return-path records, each marked Verified. Demo data.

    Your domain, signed. A DKIM keypair per domain; add the DNS records once and verify.

  • A new segment's rule, Email contains @example.com, with its live count: 12 contacts match, 12 consented. Demo data.

    Segments that stay current. Rules on contact fields and properties, with a preview of who matches before you save.

  • Retries that cannot double-send. Idempotency-Key on template sends; a retry replays the original response for 24 hours.
  • Bring your own relay. Any SMTP relay, per workspace or per domain.

ProductCraft's own transactional email goes through it.

Three more, in the same workspace.

Trawl

Describe the data. Get JSON that matches.

POST a JSON Schema and a one-sentence description; a browser agent returns data that conforms. Results arrive on a signed webhook and stay on the job record.

  1. Describe itThe schema and the sentence you send.
  2. Get JSONThe data the agent returned, checked against your schema.
  3. Hear about itSend test shows what your server answered; any event replays from a 30-day log.
See the call

Waitlist

Signups that don't live in a spreadsheet.

A demo waitlist's top referrals: Grace Hopper with 6 referrals, Alan Turing with 4 and Katherine Johnson with 2; the referral boost moved each of them to the front of the line, where they are tied at #1. Demo data.

Demo: Grace, Alan and Katherine brought in twelve.

Referrals and A/B/n variants. Positions, a leaderboard and a variant per landing page.

  • A public POST, no API key. Your landing page calls it directly; the console gives you the embed snippet.
  • Approve, then invite into your Auth app. Signed webhooks with Send test and replay, and CSV export.

Social

Feeds, follows and ranking without the rewrite.

A demo Social community's analytics, Northwind Tea Club: 6 members, 3 posts and 4 comments, each with the last 7 days. Demo data; the open-flags total and the moderation log are cropped out.

Demo: the Northwind Tea Club community.

Community analytics. Members, posts, comments and open flags, each with the last 7 days.

  • Standalone. No Auth app required.
  • Stories, polls and video. Stories with polls and close friends, DMs, and video up to 512 MB returned as a streaming-ready MP4 with a poster.

One workspace

One workspace. One key. One mental model.

One workspace owns your apps, domains, templates, waitlists, communities, jobs and API keys, and one sign-in at auth.productcraft.co reaches all five in the console.

signin.ts

import { ProductCraft } from "productcraft";

// Reads PRODUCTCRAFT_API_KEY from the environment
const pc = new ProductCraft();

const consumer = pc.auth.consumer("my-app");
const tokens = await consumer.auth.signin({
  identifier: "alice@example.com",
  password: "...",
});
import { ProductCraft } from "productcraft";

// Key from PRODUCTCRAFT_API_KEY
const pc = new ProductCraft();

const consumer = pc.auth.consumer("my-app");
const tokens = await consumer.auth.signin({
  identifier: "alice@example.com",
  password: "...",
});

200 OK

{
  "access_token": "eyJ…",
  "refresh_token": "eyJ…",
  "token_type": "Bearer",
  "expires_in": 3600
}
  • entry.createdsignedwebhook-id 6f1d…
  • email.deliveredsignedwebhook-id a83c…
  • job.succeededsignedwebhook-id 2be9…

REST-first, SDK-optional. Server-side only — every path here is in the OpenAPI spec the docs render from.

sdk
@productcraft/auth · mail · waitlist · social · trawl, plus the productcraft umbrella. Node.js / TypeScript, server-side, MIT.
webhooks
Signed webhooks on all five products, each with Send test, a 30-day event log and replay.
idempotency
Idempotency-Key on Mail sends: a retry replays the original response for 24 hours.
The editor for a demo workspace policy, demo-lp-readonly-support: its name and its description, “Support can read mail, waitlist and auth data; nothing can be deleted.”, above the Policy statements header; the statements are cropped out. Demo data.
The consent screen at auth.productcraft.co for an MCP client: Mail and Waitlist ticked among the five products, the Read-only preset, which changes nothing, then Deny and Allow access. Demo session; the client name and the workspace list above are cropped out.
Policies decide what every key and every agent can touch.

From your editor

Claude, Cursor and VS Code can work in your workspace.

An MCP server at mcp.productcraft.co. You approve the connection in the browser, a policy preset caps what it may do, and every call lands in the audit log.

claude mcp add --transport http productcraft 'https://mcp.productcraft.co/mcp' # then, inside Claude Code: /mcp # pick "productcraft" and follow the browser prompt
How many people are on the demo-lp-launch waitlist, how many came through a referral, and who are the first three in the queue?
waitlist_list_waitlists {"limit": 50}
<<<UNTRUSTED-DATA tool="waitlist_list_waitlists">
"slug": "demo-lp-launch",
"display_name": "<<untrusted> Northwind Tea: autumn menu <untrusted>>",
waitlist_get_waitlist_analytics {"waitlist_id": "…"}
<<<UNTRUSTED-DATA tool="waitlist_get_waitlist_analytics">
"total_entries": 16,
"viral_coefficient": 0.75,
"referred_count": 12,
waitlist_list_waitlist_entries {"waitlist_id": "…", "limit": 5, "is_test": false}
<<<UNTRUSTED-DATA tool="waitlist_list_waitlist_entries">
"email": "ada@example.com",
"email": "grace@example.com",
"email": "alan@example.com",

demo-lp-launch ("Northwind Tea: autumn menu") has 16 people on it, not counting test signups. All 16 are approved. All of them signed up today, 2026-11-05.

12 of the 16 came through a referral (about 75%). Those referrals came from 3 people:

- Grace Hopper: 6 referrals

- Alan Turing: 4

- Katherine Johnson: 2

First three in the queue:

1. Ada Lovelace (ada@example.com)

2. Grace Hopper (grace@example.com)

3. Alan Turing (alan@example.com), who was referred by Grace

Referral rewards have moved people up the queue. Ada, Grace, Alan and Katherine Johnson (4th) all now share effective position 1. So if you're ranking by effective position, those four are tied at the front, and the original signup order is what breaks the tie.

  • OAuth in the browser — no API key in a config file.
  • Presets: readonly, mail, support, full. Nothing that escalates privilege is ever in a preset.
  • Approve only the products it needs, and every policy-gated REST operation of those products is a tool.

Note what is not in that command: a token, a key, a client id, a secret. The only configuration is the URL.

MCP docs

Changelog

Shipped, dated, linked.

Every entry is a production deploy. The full list is on the changelog.

Pick a door

Drop in the boring half. Get back to the rest.

Open a workspace, create an API key, call the product that brought you here. The other four are on the same key.

Package manager
npm install productcraftpnpm add productcraftyarn add productcraft

Each service has a free tier large enough to ship a side project on. Pricing is coming soon.