@posthaste/sdk 0.1.0 → 0.3.0

package/dist/pagination.d.ts

@@ -1,40 +1,82 @@
 /**
  * Keyset pagination.
  *
- * The API pages by cursor rather than by offset: `limit` + `before`, answering
- * with `{ data, hasMore, nextCursor }`. `before` is the id of the last row you
- * received, which is what `nextCursor` hands you.
- *
- * THE TRAP THIS MODULE EXISTS TO CLOSE
- *
- * The obvious loop is `while (nextCursor) { … }`. It is wrong. `nextCursor` is
- * derived from the last row of a page, and at least one endpoint on this API
- * returns a non-null cursor on its final page — the documentation calls it out
- * for `/v1/inbound/messages`. A cursor loop over such an endpoint asks for the
- * page after the last one, gets an empty page with the same cursor back, and
- * spins forever. Nothing about it looks wrong in a log; it just never finishes.
- *
- * `hasMore` is the server's actual answer to "is there another page", computed
- * by fetching one row more than you asked for. It is the only correct
- * condition, so `autoPaginate` is the API this SDK puts in front of people —
- * `list` is still there for anyone who wants a single page.
+ * The API pages by cursor rather than by offset. Most lists take `limit` +
+ * `before` and answer `{ data, hasMore, nextCursor }` or `{ data, nextCursor }`,
+ * where `before` is the id of the last row you received — which is what
+ * `nextCursor` hands you.
+ *
+ * THE TWO TRAPS THIS MODULE EXISTS TO CLOSE
+ *
+ * They are mirror images, which is why neither `hasMore` nor `nextCursor` alone
+ * is a correct stopping rule across the whole API:
+ *
+ *   1. `while (nextCursor)` spins for ever on `/v1/inbound/messages`. Its cursor
+ *      is derived from the last row of the page and is set whenever the page has
+ *      any rows at all, including on the final one. A loop over it asks for the
+ *      page after the last, gets an empty page carrying the same cursor, and
+ *      never finishes. Nothing about it looks wrong in a log.
+ *
+ *   2. `if (!page.hasMore) return` stops after ONE page on `/v1/domains`,
+ *      `/v1/webhooks`, `/v1/api-keys`, `/v1/inbound/addresses`,
+ *      `/v1/billing/invoices` and `/v1/billing/history`. Those endpoints send no
+ *      `hasMore` at all, so the read is `undefined`, which is falsy, which looks
+ *      exactly like "that was everything". This is the failure that shipped: an
+ *      account with sixty invoices got fifty of them and no indication that ten
+ *      were missing.
+ *
+ * So the walker consults BOTH, and treats each as authoritative only where the
+ * server actually sends it: stop when `hasMore` is explicitly `false`, and stop
+ * when the cursor is absent or fails to advance. Every endpoint is covered by at
+ * least one of those, and no endpoint is stopped early by either.
+ */
+/**
+ * The least a response has to be for the walker to walk it.
+ *
+ * `hasMore` is optional here on purpose — that is the actual contract, and
+ * making it optional in the type is what forces every read of it to be an
+ * explicit `=== false` rather than a truthiness test.
+ */
+export interface WalkablePage<T> {
+    data: T[];
+    nextCursor: string | null;
+    hasMore?: boolean;
+}
+export type PageFetcher<TItem, TParams> = (params: TParams) => Promise<WalkablePage<TItem>>;
+/**
+ * Which request parameter carries the cursor.
+ *
+ * `before` everywhere except `/v1/billing/history`, which reads forward from a
+ * sequence number in `after`.
+ */
+export type CursorParam = 'before' | 'after';
+/**
+ * The cursor-bearing shape of a list's request parameters.
+ *
+ * Deliberately not `PaginationParams`: `/v1/billing/history` has no `before` at
+ * all, so a constraint written in terms of it would exclude the one endpoint
+ * whose cursor convention most needs a helper. Every field is optional, so any
+ * of the SDK's `List*Params` interfaces satisfies it structurally.
  */
-import type { Page, PaginationParams } from './types.js';
-export type PageFetcher<TItem, TParams> = (params: TParams) => Promise<Page<TItem>>;
+export interface CursorParams {
+    limit?: number;
+    before?: string;
+    after?: string | number;
+}
 /**
  * Walk every page and yield every item.
  *
  * Belt and braces, because an infinite loop in someone's job runner is a bad
- * way to learn about a contract change:
+ * way to learn about a contract change, and a silent truncation is a worse one:
  *
- *   - stops on `hasMore === false`, always;
+ *   - stops when the server says `hasMore: false`, on the endpoints that say it;
  *   - stops if a page comes back empty, because there is nothing to advance to;
+ *   - stops when there is no next cursor, which is how the endpoints without
+ *     `hasMore` signal the end;
  *   - stops if the cursor does not MOVE, which is what a non-null terminal
  *     cursor looks like from here.
  */
-export declare function autoPaginate<TItem extends {
-    id: string;
-}, TParams extends PaginationParams>(fetchPage: PageFetcher<TItem, TParams>, params: TParams): AsyncGenerator<TItem, void, undefined>;
+export declare function autoPaginate<TItem, TParams extends CursorParams>(fetchPage: PageFetcher<TItem, TParams>, params: TParams, cursorParam?: CursorParam): AsyncGenerator<TItem, void, undefined>;
 /**
  * Collect an auto-paginated stream into an array.
  *

package/dist/pagination.js

@@ -1,54 +1,86 @@
 /**
  * Keyset pagination.
  *
- * The API pages by cursor rather than by offset: `limit` + `before`, answering
- * with `{ data, hasMore, nextCursor }`. `before` is the id of the last row you
- * received, which is what `nextCursor` hands you.
+ * The API pages by cursor rather than by offset. Most lists take `limit` +
+ * `before` and answer `{ data, hasMore, nextCursor }` or `{ data, nextCursor }`,
+ * where `before` is the id of the last row you received — which is what
+ * `nextCursor` hands you.
  *
- * THE TRAP THIS MODULE EXISTS TO CLOSE
+ * THE TWO TRAPS THIS MODULE EXISTS TO CLOSE
  *
- * The obvious loop is `while (nextCursor) { … }`. It is wrong. `nextCursor` is
- * derived from the last row of a page, and at least one endpoint on this API
- * returns a non-null cursor on its final page — the documentation calls it out
- * for `/v1/inbound/messages`. A cursor loop over such an endpoint asks for the
- * page after the last one, gets an empty page with the same cursor back, and
- * spins forever. Nothing about it looks wrong in a log; it just never finishes.
+ * They are mirror images, which is why neither `hasMore` nor `nextCursor` alone
+ * is a correct stopping rule across the whole API:
  *
- * `hasMore` is the server's actual answer to "is there another page", computed
- * by fetching one row more than you asked for. It is the only correct
- * condition, so `autoPaginate` is the API this SDK puts in front of people —
- * `list` is still there for anyone who wants a single page.
+ *   1. `while (nextCursor)` spins for ever on `/v1/inbound/messages`. Its cursor
+ *      is derived from the last row of the page and is set whenever the page has
+ *      any rows at all, including on the final one. A loop over it asks for the
+ *      page after the last, gets an empty page carrying the same cursor, and
+ *      never finishes. Nothing about it looks wrong in a log.
+ *
+ *   2. `if (!page.hasMore) return` stops after ONE page on `/v1/domains`,
+ *      `/v1/webhooks`, `/v1/api-keys`, `/v1/inbound/addresses`,
+ *      `/v1/billing/invoices` and `/v1/billing/history`. Those endpoints send no
+ *      `hasMore` at all, so the read is `undefined`, which is falsy, which looks
+ *      exactly like "that was everything". This is the failure that shipped: an
+ *      account with sixty invoices got fifty of them and no indication that ten
+ *      were missing.
+ *
+ * So the walker consults BOTH, and treats each as authoritative only where the
+ * server actually sends it: stop when `hasMore` is explicitly `false`, and stop
+ * when the cursor is absent or fails to advance. Every endpoint is covered by at
+ * least one of those, and no endpoint is stopped early by either.
  */
 /**
  * Walk every page and yield every item.
  *
  * Belt and braces, because an infinite loop in someone's job runner is a bad
- * way to learn about a contract change:
+ * way to learn about a contract change, and a silent truncation is a worse one:
  *
- *   - stops on `hasMore === false`, always;
+ *   - stops when the server says `hasMore: false`, on the endpoints that say it;
  *   - stops if a page comes back empty, because there is nothing to advance to;
+ *   - stops when there is no next cursor, which is how the endpoints without
+ *     `hasMore` signal the end;
  *   - stops if the cursor does not MOVE, which is what a non-null terminal
  *     cursor looks like from here.
  */
-export async function* autoPaginate(fetchPage, params) {
-    let before = params.before;
+export async function* autoPaginate(fetchPage, params, cursorParam = 'before') {
+    let cursor = params[cursorParam];
     let seen;
     for (;;) {
-        const page = await fetchPage({ ...params, before });
+        const page = await fetchPage({ ...params, [cursorParam]: cursor });
         for (const item of page.data)
             yield item;
-        if (!page.hasMore)
+        // `=== false`, never `!page.hasMore`: the endpoints that omit the field
+        // must fall through to the cursor check rather than be stopped here.
+        if (page.hasMore === false)
             return;
         if (page.data.length === 0)
             return;
-        // Prefer the server's cursor; fall back to the last row's id, which is what
-        // the cursor is anyway. Either way the NEXT request must ask for something
-        // different from the last one.
-        const next = page.nextCursor ?? page.data[page.data.length - 1]?.id;
-        if (!next || next === seen)
+        /*
+         * Prefer the server's cursor. Fall back to the last row's id — which is
+         * what the cursor is anyway on every `before`-paged list — but ONLY when
+         * the server has affirmatively said there is another page.
+         *
+         * That condition is load-bearing, not caution. On the endpoints with no
+         * `hasMore`, a null `nextCursor` IS the end-of-list signal; an unconditional
+         * fallback would quietly replace it with the last row's id, and the walker
+         * would re-request the final page before the "cursor did not move" guard
+         * caught it. The fallback exists only for the opposite case — a page that
+         * claims `hasMore: true` and sends no cursor — so it is scoped to exactly
+         * that.
+         *
+         * Rows on `/v1/billing/history` have a `seq` and no `id`, so there is
+         * nothing to fall back to there in any case. Correct rather than lucky:
+         * that endpoint's `nextCursor` is null exactly on the last page.
+         */
+        const last = page.data[page.data.length - 1];
+        const next = page.nextCursor ?? (page.hasMore === true ? last?.id : undefined);
+        // Either way the NEXT request must ask for something different from the
+        // last one.
+        if (next == null || next === seen)
             return;
         seen = next;
-        before = next;
+        cursor = next;
     }
 }
 /**

package/dist/types.d.ts

@@ -12,16 +12,17 @@
  */
 import type { AccountId, ApiKeyId, DomainId, InvoiceId, MessageId, PaymentId, SubscriptionId, SuppressionId, WebhookId } from './ids.js';
 /** `message_status` in the database. The lifecycle a message can be in. */
-export declare const MESSAGE_STATUSES: readonly ['queued', 'sending', 'delivered', 'bounced', 'complained', 'failed', 'rejected'];
+export declare const MESSAGE_STATUSES: readonly ['queued', 'sending', 'delivered', 'bounced', 'complained', 'failed', 'scheduled', 'canceled', 'rejected'];
 export type MessageStatus = (typeof MESSAGE_STATUSES)[number];
 /**
- * The ten webhook event types (`event_type` in the database).
+ * The webhook event types (`event_type` in the database).
  *
  * Note that these are NOT the same set as `MessageStatus`: `accepted`,
  * `attempted`, `deferred` and `suppressed` are things that happen to a message
- * without changing the status it rests in.
+ * without changing the status it rests in. The `schedule_*` pair and
+ * `scheduled` narrate a scheduled message's life before it enters delivery.
  */
-export declare const EVENT_TYPES: readonly ['accepted', 'queued', 'attempted', 'delivered', 'deferred', 'bounced', 'complained', 'failed', 'rejected', 'suppressed'];
+export declare const EVENT_TYPES: readonly ['accepted', 'queued', 'attempted', 'delivered', 'deferred', 'bounced', 'complained', 'failed', 'rejected', 'suppressed', 'scheduled', 'schedule_canceled', 'schedule_failed'];
 export type EventType = (typeof EVENT_TYPES)[number];
 /**
  * `suppression_reason` in the database.
@@ -54,25 +55,65 @@ export type KeyEnvironment = 'live' | 'test';
 export declare const SCOPES: readonly ['account:read', 'domains:read', 'domains:write', 'emails:send', 'messages:read', 'suppressions:read', 'suppressions:write', 'webhooks:read', 'webhooks:write'];
 export type Scope = (typeof SCOPES)[number];
 /**
- * A keyset page.
+ * A keyset page carrying a cursor and nothing else.
  *
- * `hasMore` is the ONLY correct loop condition. `nextCursor` is populated from
- * the last row of a full page, and there are endpoints and edge cases where it
- * is non-null on the final page — a `while (nextCursor)` loop over those never
- * terminates. `autoPaginate` on each resource encodes the right condition so
- * this cannot be got wrong by hand.
+ * This is the shape of every list that was RETROFITTED with pagination:
+ * `/v1/domains`, `/v1/webhooks`, `/v1/api-keys`, `/v1/inbound/addresses`,
+ * `/v1/billing/invoices` and `/v1/billing/history`. They answer
+ * `{ nextCursor, data }` and send no `hasMore`.
+ *
+ * On these, `nextCursor` IS the loop condition and it is trustworthy: the
+ * handler asks the database for one row more than you did and sets the cursor
+ * only when that extra row came back, so it is null exactly when the page you
+ * are holding is the last one.
+ *
+ * Kept as a type of its own rather than folded into `Page` with an optional
+ * `hasMore`, because the two are mirror images and confusing them is the whole
+ * bug class. On a `Page` the server's `hasMore` is authoritative and the cursor
+ * is not; here there is no `hasMore` to consult at all — and code that reads
+ * `page.hasMore` off one of these gets `undefined`, treats it as "no more", and
+ * stops after the first page. That is the silent truncation this split exists
+ * to make unwritable.
  */
-export interface Page<T> {
+export interface CursorPage<T> {
     data: T[];
-    hasMore: boolean;
     nextCursor: string | null;
 }
-/** A list that is not paginated. Returned whole. */
-export interface List<T> {
-    data: T[];
+/**
+ * A keyset page that also carries the server's own answer to "is there more?".
+ *
+ * Sent by `/v1/messages`, `/v1/suppressions` and `/v1/inbound/messages` — the
+ * lists that were paginated from the start.
+ *
+ * Here `hasMore` is the ONLY correct loop condition. `nextCursor` is populated
+ * from the last row of a page, and `/v1/inbound/messages` returns a non-null
+ * cursor on its final page — a `while (nextCursor)` loop over that endpoint
+ * never terminates. `autoPaginate` on each resource encodes the right condition
+ * so neither half of this can be got wrong by hand.
+ */
+export interface Page<T> extends CursorPage<T> {
+    hasMore: boolean;
 }
+/**
+ * @deprecated `List` meant "a list the API returns WHOLE, with no cursor".
+ * There is no such list any more — every one of them now pages, and a caller
+ * that treats the first response as complete silently loses everything past the
+ * first page. It is an alias of {@link CursorPage} so existing imports keep
+ * compiling; read `nextCursor`, or use the resource's `autoPaginate`.
+ */
+export type List<T> = CursorPage<T>;
+/**
+ * The cursor convention shared by every list except `/v1/billing/history`,
+ * which reads FORWARD from a sequence number — see
+ * {@link ListBillingHistoryParams}.
+ */
 export interface PaginationParams {
-    /** Page size. Messages cap at 100, suppressions at 200. */
+    /**
+     * Page size. The bound and the default are per-endpoint: 1–100 default 25 for
+     * messages and inbound messages, 1–200 default 50 for suppressions, 1–100
+     * default 50 for webhooks, API keys, inbound addresses and invoices, and
+     * 1–100 default 100 for domains.
+     */
     limit?: number;
     /** The `nextCursor` from the previous page. */
     before?: string;
@@ -154,6 +195,16 @@ export interface DnsRecord {
     /** Present when publishing the record carries a risk (SPF, DMARC). */
     warning?: string;
 }
+export interface ListDomainsParams extends PaginationParams {
+    /**
+     * 1–100, default 100.
+     *
+     * The default is the maximum here, so the first page is every domain on all
+     * but the largest accounts — but it is a page, not the whole list, and past
+     * a hundred domains `nextCursor` is how you reach the rest.
+     */
+    limit?: number;
+}
 export interface CreateDomainParams {
     name: string;
 }
@@ -237,7 +288,29 @@ export interface CloudflarePublishResult {
 }
 export interface SendEmailParams {
     from: string;
-    to: string;
+    /**
+     * One address, or up to 50 across `to`, `cc` and `bcc` combined.
+     *
+     * `to: 'x'` and `to: ['x']` are the same request. Every recipient becomes
+     * its own message with its own delivery record and its own bounce
+     * attribution — which is also why every recipient counts as one send
+     * against your allowance. See `cc`.
+     */
+    to: string | string[];
+    /**
+     * Named on the other copies, and charged like any other recipient.
+     *
+     * A Cc is not a free rider on somebody else's message: it is delivered
+     * separately, so a message to one `to` and two `cc` costs three.
+     */
+    cc?: string[];
+    /**
+     * Delivered, and named nowhere.
+     *
+     * A blind copy is its own message that lists no other recipient — there is
+     * no Bcc header on anything we send. Charged like the others.
+     */
+    bcc?: string[];
     subject?: string;
     text?: string;
     html?: string;
@@ -253,6 +326,45 @@ export interface SendEmailParams {
      * retry; without it a send is never retried automatically.
      */
     idempotencyKey?: string;
+    /**
+     * Up to 10 files, at most 10 MiB combined (decoded). `content` is the raw
+     * bytes — pass a `Uint8Array`/`Buffer` and the SDK base64-encodes it, or a
+     * string that is ALREADY base64 (it is sent as-is, never double-encoded).
+     * Executable types (`.exe`, `.js`, `.bat`, …) are refused by the API with
+     * `attachment_type_blocked` — the big mailbox providers bounce them anyway.
+     * For an inline image referenced from the html as `<img src="cid:logo">`,
+     * set `disposition: 'inline'` and `cid: 'logo'`.
+     */
+    attachments?: SendAttachment[];
+    /**
+     * Send later — ISO-8601 with an offset (what `Date.toISOString()` makes).
+     * At most 7 days ahead; within 60 seconds is treated as an immediate send.
+     * Quota is decided on the SEND day, and the message is cancellable with
+     * `emails.cancelSchedule(id)` until it is released.
+     */
+    scheduledAt?: string;
+}
+export interface SendAttachment {
+    /** Shown to the recipient. No path separators; 255 chars max. */
+    filename: string;
+    /** `type/subtype` only — no parameters. */
+    contentType: string;
+    /** Raw bytes, or a string already base64-encoded. */
+    content: Uint8Array | string;
+    disposition?: 'attachment' | 'inline';
+    /** Content-ID for inline parts, referenced as `cid:` from the html. */
+    cid?: string;
+}
+/** What happened to one recipient of a multi-recipient send. */
+export interface SentCopy {
+    /** Absent when the recipient was skipped. */
+    id?: MessageId;
+    to: string;
+    /** Which field the address was taken from, after de-duplication. */
+    kind: 'to' | 'cc' | 'bcc';
+    status: 'queued' | 'scheduled' | 'duplicate' | 'suppressed';
+    /** Why it was skipped: `hard_bounce`, `complaint`, `spam_trap`, `manual`. */
+    reason?: string;
 }
 export interface SendEmailResult {
     id: MessageId;
@@ -261,7 +373,7 @@ export interface SendEmailResult {
      * (HTTP 200). Both are success, and both carry the id of the one real
      * message.
      */
-    status: 'queued' | 'duplicate';
+    status: 'queued' | 'scheduled' | 'duplicate';
     /**
      * True when this request matched an earlier one by `idempotencyKey` and no
      * new message was created. Surfaced rather than hidden, because "we did
@@ -269,6 +381,30 @@ export interface SendEmailResult {
      * answer from "accepted".
      */
     duplicate: boolean;
+    /** Echoed back for a scheduled send. */
+    scheduledAt?: string;
+    /**
+     * Ties the copies of a multi-recipient send together. Absent for a single
+     * recipient, which has nothing to be grouped with.
+     */
+    groupId?: string;
+    /**
+     * Every requested recipient, exactly once — present only when there was more
+     * than one. `id` is the FIRST To copy and is kept so code reading
+     * `{ id, status }` still works, but this array is what is authoritative.
+     */
+    emails?: SentCopy[];
+    /**
+     * Recipients that were skipped because they are suppressed.
+     *
+     * Repeated here as well as in `emails` deliberately: a recipient we did not
+     * send to is the one outcome that must be impossible to miss. A suppressed
+     * address is never sent to and never charged.
+     */
+    suppressed?: {
+        to: string;
+        reason: string;
+    }[];
 }
 export interface ListMessagesParams extends PaginationParams {
     /** Max 100, default 25. */
@@ -310,9 +446,26 @@ export interface MessageContent {
     raw: string | null;
     replyTo: string | null;
     headers: Record<string, string>;
+    /**
+     * Metadata only — download the bytes with `emails.downloadAttachment`.
+     * Empty array for a message sent without attachments; the whole `content`
+     * object is null once the body ages out of retention, attachments with it.
+     */
+    attachments: AttachmentMeta[];
+}
+export interface AttachmentMeta {
+    /** Bare uuid, used in the download URL. */
+    id: string;
+    filename: string;
+    contentType: string;
+    disposition: 'attachment' | 'inline' | (string & {});
+    cid: string | null;
+    sizeBytes: number;
 }
 export interface Message {
     id: MessageId;
+    /** Present on anything that was ever scheduled; `status` says whether it still is. */
+    scheduledAt?: string;
     /** The hash chain over this message's own events was re-verified on read. */
     recordIntact: boolean;
     /** Present only when `recordIntact` is false. */
@@ -417,6 +570,10 @@ export interface CreatedSuppression {
     address: string;
     reason: 'manual';
 }
+export interface ListWebhooksParams extends PaginationParams {
+    /** 1–100, default 50. */
+    limit?: number;
+}
 export interface CreateWebhookParams {
     /** http or https only. */
     url: string;
@@ -453,6 +610,10 @@ export interface WebhookEvent {
         detail?: Record<string, unknown>;
     };
 }
+export interface ListApiKeysParams extends PaginationParams {
+    /** 1–100, default 50. Revoked keys are listed too and count towards it. */
+    limit?: number;
+}
 export interface ApiKey {
     id: ApiKeyId;
     name: string;
@@ -549,14 +710,57 @@ export interface BillingEvent {
     occurredAt: string;
     hash: string;
 }
-export interface BillingHistory {
-    /** The chain replayed in the database, so the record can be checked. */
+/**
+ * `/v1/billing/history` pages by SEQUENCE NUMBER, and forwards.
+ *
+ * It is the one list on this API that does not use `limit` + `before`, and the
+ * difference is not cosmetic. The billing record is a hash chain, a chain reads
+ * forward from its start, and the order it renders in has to be the order it
+ * verifies in — so this endpoint is ascending, oldest first, and resumes from
+ * `after` rather than `before`. Everything else on the API is newest-first and
+ * resumes from a row id.
+ *
+ * Two things follow that a caller cannot guess:
+ *
+ *   - `after` is a `BillingEvent.seq` — a number — not a `bil_`-style id. The
+ *     server rejects anything that is not a non-negative integer with `400
+ *     invalid_request`.
+ *   - The page you get back is the events AFTER that sequence number, so the
+ *     natural resume value is the `seq` of the last event you have processed.
+ *     `nextCursor` already is exactly that, as a string.
+ */
+export interface ListBillingHistoryParams {
+    /** 1–200, default 100. Wider than the rest of the API, because it is a ledger. */
+    limit?: number;
+    /**
+     * A sequence number, NOT an id. Returns the events whose `seq` is strictly
+     * greater. `nextCursor` from the previous page is the value to pass.
+     */
+    after?: string | number;
+}
+export interface BillingHistory extends CursorPage<BillingEvent> {
+    /**
+     * The chain replayed in the database, so the record can be checked.
+     *
+     * Verified over the WHOLE account history, not over the page — so it means
+     * the same thing on page four as on page one, and paging does not weaken it.
+     */
     chain: {
         valid: boolean;
         brokenAt: number | null;
         reason: string | null;
     };
+    /** Oldest first — the opposite of every other list. */
     data: BillingEvent[];
+    /**
+     * The `seq` of the last event on this page, as a string, or `null` when this
+     * is the last page. Pass it as `after`.
+     */
+    nextCursor: string | null;
+}
+export interface ListInvoicesParams extends PaginationParams {
+    /** 1–100, default 50. */
+    limit?: number;
 }
 export interface Invoice {
     id: InvoiceId;

package/dist/types.js

@@ -21,14 +21,17 @@ export const MESSAGE_STATUSES = [
     'bounced',
     'complained',
     'failed',
+    'scheduled',
+    'canceled',
     'rejected',
 ];
 /**
- * The ten webhook event types (`event_type` in the database).
+ * The webhook event types (`event_type` in the database).
  *
  * Note that these are NOT the same set as `MessageStatus`: `accepted`,
  * `attempted`, `deferred` and `suppressed` are things that happen to a message
- * without changing the status it rests in.
+ * without changing the status it rests in. The `schedule_*` pair and
+ * `scheduled` narrate a scheduled message's life before it enters delivery.
  */
 export const EVENT_TYPES = [
     'accepted',
@@ -41,6 +44,9 @@ export const EVENT_TYPES = [
     'failed',
     'rejected',
     'suppressed',
+    'scheduled',
+    'schedule_canceled',
+    'schedule_failed',
 ];
 /**
  * `suppression_reason` in the database.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@posthaste/sdk",
-  "version": "0.1.0",
+  "version": "0.3.0",
   "description": "Official TypeScript SDK for the Posthaste transactional email API.",
   "license": "MIT",
   "publishConfig": {