Email

Email API

Signup confirmations, magic links, receipts, alerts — your product's mail should ride the same verified domain and show up in the same tracking history as everything else. The API is a small, boring, REST-shaped surface for exactly that.

Authentication

Create a key in Email → Setup → API. Keys are named (one per environment or integration), shown once in full at creation, and revocable individually — with created and last-used timestamps so dead keys are easy to spot.

Send it as a bearer token against the base URL:

Authorization: Bearer gsf_live_...
Base URL: https://goshipfast.com/api/v1

Sending

POST /emails with from (an address at your verified domain), to, subject, and either html or a templateId plus variables for merge fields. Optional: replyTo, and an Idempotency-Key header — retry the request as many times as your network requires; the mail sends once.

A successful call returns 202 with a message id and status queued. Then:

  • GET /emails/:id — the delivery lifecycle: queued → sent → opened / clicked, or bounced / failed with the reason.

Every API send also appears in Tracking → History, so debugging doesn't require log-diving.

Contacts and events

  • POST /contacts — add or update a recipient (email plus attributes). DELETE /contacts/:email removes them.
  • POST /events — report that something happened ("user_signed_up", "trial_ending"). Events are the trigger side of workflows: an automation configured to fire on an event sends its sequence to that contact. This is how product-lifecycle email (onboarding drips, win-backs) runs without your code knowing anything about sequences — your app states facts, the workflow decides what mail they deserve.

Limits and errors

  • Rate limit: 120 requests per minute per key.
  • Volume: API sends draw from the same plan quotas as everything else — including the daily cap that protects your sender reputation. A 429 or quota error means slow down, not retry harder.
  • Errors are conventional: 401 bad key, 403 unverified domain or not-your-resource, 422 validation with a field-level message.

The in-product Docs tab (Email → Setup → Docs) carries the full reference with a runnable Node example and the inbound webhook signature recipe.

A sane integration

  1. Verify a sending domain; create one key per environment.
  2. Route transactional mail through POST /emails with idempotency keys.
  3. Emit POST /events at your product's lifecycle moments — even before any workflow uses them. The triggers cost nothing and are ready the day you build the sequence.
  4. Keep secrets server-side; the key authorizes sending as your brand.