コンテンツにスキップ
spacepostドキュメント

セキュリティと API キー

キーの種類

Section titled “キーの種類”
権限 できること 用途
full_access すべてのエンドポイント ご自身のツール、CLI、MCP サーバー、管理用スクリプト
sending_access POST /emails と POST /emails/batch のみ メールを送信するだけのアプリケーションサーバー

sending_access キーで他のエンドポイントを呼び出すと、401 restricted_api_key(“This API key is restricted to only send emails”)が返ります。

ドメインを限定したキー

Section titled “ドメインを限定したキー”

sending_access キーは、domain_id で1 つのドメインにさらに紐付けられます。その場合、そのドメインのアドレスからしか送信できず、他の from は 401 restricted_api_key を返します。製品やクライアントごとに専用のキーを発行するのに使えます。

api-keys.ts
import { SpacePost } from "@spacepost/node";


const spacepost = new SpacePost();


// A key that can only send, and only from one domain.
const { data: key, error } = await spacepost.apiKeys.create({
  name: "worker-prod",
  permission: "sending_access",
  domainId: "0192e1c4-0000-7000-8000-000000000001",
});
if (error) throw new Error(error.message);
console.log(key.token); // sp_live_..., shown only once


const { data: keys } = await spacepost.apiKeys.list();
console.log(keys?.data.map((k) => `${k.name} ${k.prefix}... ${k.permission}`));


await spacepost.apiKeys.remove(key.id);

name は 1 〜 50 文字です。domain_id は sending_access でのみ指定できます。

キーの保存方法

Section titled “キーの保存方法”
  • キーは sp_live_ に続けて、base62 のランダムな 32 文字で構成されます。
  • SpacePost が保存するのは SHA-256 ハッシュだけです。完全なキーが表示されるのは、作成時の 1 回だけです。紛失した場合は、新しいキーを作成してください。
  • ダッシュボードと GET /api-keys には、プレフィックス(sp_live_ に 4 文字)、権限、ドメイン、last_used_at が表示されます。
  • キーを削除する(DELETE /api-keys/{id})と、直ちに無効になります。

良い習慣

Section titled “良い習慣”
  • キーをクライアント側のコード、モバイルアプリ、公開リポジトリに絶対に入れないでください。API がクロスオリジンのリクエストを許可しているのは、API プレイグラウンドを動かすためだけです。メールはサーバーから送信してください。
  • サービスと環境ごとに 1 つのキーを使い、分かりやすい名前を付けます(worker-prod、ci-staging)。
  • sending_access を優先し、ドメインを限定します。
  • ローテーションは、新しいキーを作成してデプロイし、古いキーの last_used_at を確認してから、古いキーを削除する手順で行います。
  • キーは、コードではなく、シークレットマネージャーまたは環境変数に保管します。
  • キーが漏えいしたら、直ちに無効化してください。GitHub にコミットされた場合は、侵害されたものとみなしてください。
  • SMTP でも、同じキーをパスワードとして使います。SMTP リレーをご覧ください。

通信

Section titled “通信”

すべての通信は TLS を使います。API は https://api.spacepost.dev で提供されます。smtp.spacepost.dev:25976 の SMTP リレーでは、認証の前に STARTTLS が必須です(ポート 465 での暗黙的 TLS はまだ提供していません)。

その他の保護策: SMTP の認証失敗は IP ごとにスロットルされます。Webhook のエンドポイントと添付ファイルの URL は公開アドレスに解決される必要があり(プライベートネットワークは拒否されます)、配信停止リンクはコンタクトごとに署名されます。

データの保存場所

Section titled “データの保存場所”

SpacePost は、スロベニアの EU 企業である Studio 404 d.o.o. が運営しており、お客様のデータを EU 内に保管します。

  • 送信: AWS eu-central-1(ドイツ、フランクフルト)の Amazon SES。すべてのドメインがこのリージョンから送信します。
  • アプリケーションとデータベース: API、ダッシュボード、ワーカー、Postgres データベースは、Railway の EU リージョン(オランダ、アムステルダム)で動作しています。
  • 分離: 各チームは専用の SES テナントを通じて送信するため、あるお客様のレピュテーションの問題が他のお客様に影響しません。
  • Web サイトとドキュメントは、Cloudflare のグローバルネットワークから配信される静的ページです。お客様のデータは保存されません。

一部のプロバイダー(AWS、Stripe、Railway)は米国企業です。処理する内容と場所は、サブプロセッサーの一覧(英語)に記載しています。GDPR のデータ処理補遺(英語)は利用規約の一部で、利用規約はスロベニア法に準拠します。

脆弱性を報告する

Section titled “脆弱性を報告する”

詳細を書いて support@spacepost.dev にメールしてください。他のお客様のデータに対してはテストしないでください。