Introduction

Authorization: Bearer mk_xxxxxxxx...
Content-Type: application/json

curl 'https://www.mailkaka.in/api/api-keys/validate' \
  -H 'Authorization: Bearer mk_xxxxxxxx...'

{
  "valid": true,
  "key": { "name": "Production", "permissions": ["send"] },
  "domain": { "domain": "yourcompany.in", "status": "verified" },
  "organization": { "name": "Your Company" }
}

curl -X POST 'https://www.mailkaka.in/api/emails' \
  -H 'Authorization: Bearer mk_xxxxxxxx...' \
  -H 'Content-Type: application/json' \
  -d '{
    "from": "hello@yourcompany.in",
    "to": ["customer@example.com"],
    "subject": "Your order is confirmed",
    "html": "<strong>Shipped from India.</strong>"
  }'

await fetch('https://www.mailkaka.in/api/emails', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.MAILKAKA_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    from: 'hello@yourcompany.in',
    to: ['customer@example.com'],
    subject: 'Your order is confirmed',
    html: '<strong>Shipped from India.</strong>',
  }),
});

const response = await fetch('https://www.mailkaka.in/api/emails/batch', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.MAILKAKA_API_KEY}`,
    'Content-Type': 'application/json',
    'Idempotency-Key': 'order-notifications-2026-08-03',
  },
  body: JSON.stringify([
    {
      from: 'Acme <hello@yourcompany.in>',
      to: ['first@example.com'],
      subject: 'Your first update',
      html: '<strong>First message</strong>',
    },
    {
      from: 'Acme <hello@yourcompany.in>',
      to: ['second@example.com'],
      subject: 'Your second update',
      html: '<strong>Second message</strong>',
    },
  ]),
});

{
  "data": [
    { "id": "..." },
    { "id": "..." }
  ]
}

GET https://www.mailkaka.in/api/emails/logs
Authorization: Bearer mk_xxxxxxxx...

X-Mailkaka-Signature: <hex HMAC-SHA256 of the raw request body, keyed with your endpoint's whsec_ secret>

{ "error": "From email must be from domain: yourcompany.in" }

You are migrating a codebase from Resend (https://resend.com) to MailKaka (https://www.mailkaka.in), an India-first transactional email and business mailbox platform. Full reference: https://www.mailkaka.in/docs.md

Do the following:

1. Find every use of the Resend SDK/API in this repo: `new Resend(...)`, `resend.emails.send(...)`, `resend.batch.send(...)`, the `RESEND_API_KEY` env var, and any raw HTTP calls to `api.resend.com`.

2. Base URL and auth:
   - Replace the Resend base URL with MailKaka's: https://www.mailkaka.in/api
   - Replace `RESEND_API_KEY` with a MailKaka key (starts with `mk_`) in an env var such as `MAILKAKA_API_KEY`.
   - Existing Resend Node SDK single-message sends can usually be migrated by passing `baseURL` in the constructor: `new Resend(MAILKAKA_API_KEY, { baseURL: 'https://www.mailkaka.in/api' })`. Raw HTTP/cURL callers just change the host and Bearer token.

3. Sender addresses: MailKaka accepts both `from: 'email@domain.com'` and `from: 'Display Name <email@domain.com>'`. The inner email address must belong to the verified domain scoped to the API key.

4. `to`/`cc`/`bcc` behavior matches Resend: pass an array of addresses in one request; do not fan a multi-recipient send out into one request per recipient. Exception: if the code opts into MailKaka's `unsubscribe: true` field, that requires exactly one `to` recipient per request -- Resend has no equivalent flag, so only handle this if you're adding new MailKaka-specific behavior, not as part of a like-for-like migration.

5. Batch sends: MailKaka implements `POST /emails/batch` for arrays of 1-100 messages and returns `{ data: [{ id }] }` in request order. Existing `resend.batch.send(...)` calls can use it after the same base URL and key change. The full batch is rejected before queueing if any item is invalid. Preserve any existing `Idempotency-Key` header; MailKaka uses it to deduplicate the whole batch.

6. Webhooks: MailKaka only emits `sent`, `delivered`, `bounced`, `complained` events, signed via HMAC-SHA256 in an `X-Mailkaka-Signature` header (verify the same way you'd verify Resend's `svix-signature`, just with a plain HMAC of the raw body instead of Svix). MailKaka has no `opened`/`clicked` tracking events and no customer-facing inbound-email webhook -- inbound mail is instead delivered into MailKaka's own hosted team mailbox, not forwarded to your endpoint. If the code has handlers for those Resend event types, flag them clearly as unsupported rather than silently dropping the logic; do not fabricate a workaround.

7. Error shapes differ: MailKaka returns HTTP 400 (not 422) for request-validation failures, 401 for a missing/invalid API key, 403 for a key without send permission (or an unverified/suspended sending domain), and 429 when the plan's monthly send quota is exhausted. Update any status-code-specific error handling accordingly.

8. Before cutting over traffic, call `GET https://www.mailkaka.in/api/api-keys/validate` with the new key (`Authorization: Bearer mk_...`) to confirm it's live and see its permissions/domain without sending a real email.

Ask the user before removing any Resend-specific code you're not fully certain has a MailKaka equivalent -- prefer flagging an unsupported feature over deleting working logic.