Use the MailKite SDK with the local server's supported API
Point the client at your own backend, use a local account key, and distinguish the documented compatibility subset from hosted-only features.
Reviewed
MailKite Server’s developer API contract documents a compatible send/read subset. It explicitly does not implement every MailKite Cloud method; using the same SDK cannot create missing local features.
Connect the client to the intended backend
Install mailkite, provision an approved local account key through the server’s supported tooling, and supply the actual backend URL securely. This read-only example makes no send request:
import { MailKite } from "mailkite";
for (const key of ["MAILKITE_LOCAL_KEY", "MAILKITE_LOCAL_URL"]) {
if (!process.env[key]) throw new Error(`Missing ${key}`);
}
const client = new MailKite(
process.env.MAILKITE_LOCAL_KEY,
process.env.MAILKITE_LOCAL_URL,
);
const messages = await client.listMessages();
console.log({ count: messages.length });The local contract returns an account-wide list; do not treat it as an address-scoped agent grant. Keep keys server-side and configure TLS/access controls for a non-local HTTP deployment.
Check sending boundaries before a real message
The local sender domain must belong to the key’s account. External delivery requires the configured smarthost; API compatibility is not a built-in warmed sending network. The documented no-smarthost and smarthost-failure cases need application-specific handling, including uncertain/partially stored outcomes before retrying.
Templates, scheduling, attachments, and tracking do not acquire Cloud behavior simply because the SDK accepts related options. Review explicit unsupported/no-op fields in the pinned local contract and test only supported operations. Verify message identity and provider handoff separately from recipient delivery; do not auto-fail over and send the same operation twice.