@spree/docs 0.1.268 → 0.1.270

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -399,6 +399,8 @@ Store Credits and Gift Cards work differently at checkout:
399
399
  - **Store Credits** - Require a customer account; applied from the customer's balance
400
400
  - **Gift Cards** - Can be used by anyone (guests included); applied directly to the order via code
401
401
 
402
+ Both are applied before the customer chooses how to pay, and neither appears among the cart's payment methods. An order uses one or the other, never both. A gift card covers as much of the total as its balance allows and keeps up as the total changes. See the [cart & checkout SDK guide](../sdk/store/cart-checkout.md) for the calls.
403
+
402
404
  ### Checkout Flow
403
405
 
404
406
  ```mermaid
@@ -13,7 +13,7 @@ Spree handles two categories of emails:
13
13
 
14
14
  ## Customer-Facing Emails
15
15
 
16
- By default, **Spree sends all customer transactional emails itself** — the `spree_emails` gem ships installed in every deployment. This works for every client of the API: mobile apps, custom frontends, POS integrations — no storefront required. Delivery uses the same [SMTP configuration](#configuration) as system emails.
16
+ By default, **Spree sends all customer transactional emails itself**. This works for every client of the API: mobile apps, custom frontends, POS integrations — no storefront required. Delivery uses the same [SMTP configuration](#configuration) as system emails.
17
17
 
18
18
  Customer emails can be turned off in the admin under **Settings → Emails** — do this when your storefront takes over sending them (below), otherwise customers receive both.
19
19
 
@@ -89,10 +89,12 @@ Set the following environment variables on the **Spree backend** to enable email
89
89
  | `SMTP_USERNAME` | — | SMTP auth username |
90
90
  | `SMTP_PASSWORD` | — | SMTP auth password |
91
91
  | `SMTP_FROM_ADDRESS` | — | Default "from" email address (e.g., `admin@mystore.com`) |
92
- | `RAILS_HOST` | `example.com` | Public host used in email links and other [generated URLs](environment_variables.md#urls-and-hosts) — image/attachment URLs use `CDN_HOST` instead when set |
92
+ | `SPREE_HOST` | `example.com` | Public host used in email links and other [generated URLs](environment_variables.md#urls-and-hosts) — image/attachment URLs use `CDN_HOST` instead when set |
93
93
 
94
94
  When `SMTP_HOST` is not set, emails are printed to the Rails log instead of being sent.
95
95
 
96
+ Any SMTP provider works — there is nothing provider-specific to install. For how the configuration behaves and what to weigh when choosing between providers, see [Emails](../providers/emails.md). Step-by-step setup for each one: [Resend](../../integrations/email/resend.md), [Postmark](../../integrations/email/postmark.md), [SendGrid](../../integrations/email/sendgrid.md), [Mailgun](../../integrations/email/mailgun.md) and [Amazon SES](../../integrations/email/amazon-ses.md).
97
+
96
98
  ### Provider Examples
97
99
 
98
100
  **SendGrid:**
@@ -0,0 +1,79 @@
1
+ ---
2
+ title: Emails
3
+ description: Spree sends transactional email over plain SMTP, configured entirely by environment variable — any provider works, and none of them needs anything installed.
4
+ ---
5
+
6
+ Every transactional email Spree sends — order confirmations, shipping notifications, password resets, staff invitations — goes out over SMTP. There is nothing to install and no integration to connect: you give Spree an SMTP host and credentials through environment variables, and it sends.
7
+
8
+ This makes email the one provider category that is **not** configured per store in the admin. Payment gateways, tax engines and search each hold their credentials as a [store integration](overview.md); email is infrastructure for the whole deployment, so it lives in the environment alongside the database URL.
9
+
10
+ For what Spree sends, when, and how a storefront can take the customer-facing mail over instead, see [Sending out Emails](../deployment/emails.md).
11
+
12
+ ## Configuration
13
+
14
+ Set these on the Spree backend:
15
+
16
+ ```bash
17
+ SMTP_HOST=smtp.resend.com
18
+ SMTP_PORT=587
19
+ SMTP_USERNAME=resend
20
+ SMTP_PASSWORD=re_your_api_key
21
+ SMTP_FROM_ADDRESS=orders@yourstore.com
22
+ ```
23
+
24
+ | Variable | Default | What it does |
25
+ | --- | --- | --- |
26
+ | `SMTP_HOST` | — | The provider's SMTP server. **Setting this is what turns on SMTP delivery** — leave it unset and nothing is configured |
27
+ | `SMTP_PORT` | `587` | The port to connect on |
28
+ | `SMTP_USERNAME` | — | The SMTP user. Optional: when it is absent Spree connects without authenticating |
29
+ | `SMTP_PASSWORD` | — | The SMTP password, sent only when a username is set |
30
+ | `SMTP_FROM_ADDRESS` | — | The default From address on outgoing mail |
31
+ | `SPREE_HOST` | `example.com` | The public host used to build links inside emails — see [environment variables](../deployment/environment_variables.md#urls-and-hosts) |
32
+
33
+ Two details are worth knowing because they decide whether a provider will accept your connection at all:
34
+
35
+ - **STARTTLS is always attempted.** Spree upgrades the connection to TLS whenever the server offers it, which is what every provider below expects on port 587. It does not open a connection that is implicitly TLS from the first byte, so a provider's "SSL" port — usually 465 — is the wrong choice here. Use the STARTTLS port.
36
+ - **Authentication is optional, and plain when used.** Credentials are sent only if `SMTP_USERNAME` is set, which is how the quickstart delivers to a local mail catcher with no account at all. When it is set, Spree authenticates with the `plain` mechanism over the encrypted connection — the one every provider below documents for SMTP.
37
+
38
+ > **NOTE:** `SMTP_FROM_ADDRESS` sets the application-wide default. Merchants can override the From and Reply-To addresses per store in the admin under **Settings → Emails** — see the [email settings guide](/user/settings/emails).
39
+
40
+ ## Choosing a provider
41
+
42
+ Any service that speaks SMTP works. Because the integration is identical, the choice is about everything *around* sending rather than anything in Spree:
43
+
44
+ - **Deliverability and reputation.** Whether mail lands in the inbox is mostly the provider's IP reputation plus your domain authentication, not your code.
45
+ - **Domain authentication.** Every provider will ask you to prove you own your sending domain with DNS records. This is the single highest-value thing you can do for deliverability, and it is not optional in practice.
46
+ - **Sending limits and pricing.** Free and trial tiers are usually capped by volume, and several restrict *who* you may send to until you verify a domain.
47
+ - **Bounces and complaints.** Spree does not process bounce notifications. Handling a hard bounce or a spam complaint is the provider's dashboard and webhooks, which differ a lot between them.
48
+ - **Analytics.** Open and click tracking, message logs and retention are provider features.
49
+
50
+
51
+ - [Resend](../../integrations/email/resend.md) — Developer-focused and quick to set up.
52
+ - [Postmark](../../integrations/email/postmark.md) — Built around transactional mail and fast delivery.
53
+ - [SendGrid](../../integrations/email/sendgrid.md) — Long-established, high volume.
54
+ - [Mailgun](../../integrations/email/mailgun.md) — Flexible routing, US and EU regions.
55
+ - [Amazon SES](../../integrations/email/amazon-ses.md) — Cheapest at scale if you already run on AWS.
56
+
57
+
58
+ ## Verifying delivery
59
+
60
+ After setting the variables and restarting the application, send a real message rather than trusting the configuration:
61
+
62
+ 1. Trigger an email — inviting a staff member under **Settings → Users** is the quickest, since it needs no order.
63
+ 2. Check the provider's own activity or message log. This is the honest answer: it tells you whether the provider accepted the message, and whether it then bounced.
64
+ 3. If nothing arrives, read the application logs. An SMTP rejection surfaces there with the provider's own error text, which normally names the cause — an unverified sender, a bad credential, or a sandbox restriction.
65
+
66
+ The most common failures are not configuration mistakes in Spree:
67
+
68
+ | Symptom | Usual cause |
69
+ | --- | --- |
70
+ | Emails are written to the log instead of sent | `SMTP_HOST` is not set, so SMTP delivery was never switched on |
71
+ | Authentication fails | The username is not what the provider expects — several want a fixed literal rather than your account email |
72
+ | The provider rejects the sender | `SMTP_FROM_ADDRESS` is a domain you have not authenticated with that provider |
73
+ | Mail is accepted but never arrives | A new account restricted to verified recipients, or mail landing in spam because the domain is not authenticated |
74
+
75
+ > **NOTE:** **Every provider restricts new accounts**, so a first test email that never arrives is usually the account, not your configuration. Amazon SES starts in a sandbox that only reaches verified addresses, Postmark reviews accounts before they can mail customers, Mailgun's sandbox reaches five named recipients, and Resend only emails you until a domain is verified. Authenticate your domain and clear the provider's restriction before treating a missing email as a bug.
76
+
77
+ ## Local development
78
+
79
+ In development nothing is delivered externally. Emails are captured by [Mailpit](https://mailpit.axllent.org), which you read at `http://localhost:8025`. To exercise a real provider locally, set `SMTP_HOST` and the rest in `.env` — but point `SMTP_FROM_ADDRESS` at a domain you have authenticated, or the provider will reject it.
@@ -77,6 +77,8 @@ const cart = await client.carts.giftCards.apply(cartId, 'GC-ABCD-1234', options)
77
77
  await client.carts.giftCards.remove(cartId, 'gc_abc123', options);
78
78
  ```
79
79
 
80
+ A gift card pays as much of the total as its balance allows, and its share keeps up when delivery, discounts or tax change the total. A cart can use a gift card or store credit, not both.
81
+
80
82
  ### Fees and Duties
81
83
 
82
84
  A cart may carry charges that are neither a product price nor tax: gift wrapping, a handling charge, a cash-on-delivery surcharge, or an import duty on a cross-border order. Each is a [fee](../../core-concepts/fees.md) on the cart, and the storefront should show every one of them before the customer pays.
@@ -174,6 +176,8 @@ await client.carts.storeCredits.apply(cartId, 25.00, options);
174
176
  await client.carts.storeCredits.remove(cartId, options);
175
177
  ```
176
178
 
179
+ Store credit is a balance, not one of the cart's `payment_methods`: apply it here, then collect whatever `amount_due` is left with a payment method. It can't be combined with a gift card on the same cart.
180
+
177
181
  ### Totals
178
182
 
179
183
  The cart and order responses break the amount the customer pays into these totals. Each has a raw string value and a `display_` twin formatted in the cart's currency.
@@ -0,0 +1,69 @@
1
+ ---
2
+ title: Amazon SES
3
+ description: Send Spree's transactional emails through Amazon SES over SMTP — regional endpoints, credentials that are not your IAM keys, and the sandbox to leave before launch.
4
+ ---
5
+
6
+ [Amazon SES](https://aws.amazon.com/ses/) is AWS's email service and the cheapest option at volume. It is the natural choice for a store already running on AWS, at the cost of more setup than the other providers: credentials work differently from the rest of AWS, and every new account starts restricted.
7
+
8
+ Spree talks to SES over plain SMTP, so there is nothing to install — see [Emails](../../developer/providers/emails.md) for how the configuration works.
9
+
10
+ ## Configuration
11
+
12
+ ```bash
13
+ SMTP_HOST=email-smtp.us-east-1.amazonaws.com
14
+ SMTP_PORT=587
15
+ SMTP_USERNAME=your_ses_smtp_username
16
+ SMTP_PASSWORD=your_ses_smtp_password
17
+ SMTP_FROM_ADDRESS=orders@yourstore.com
18
+ ```
19
+
20
+ The host follows the pattern `email-smtp.<region>.amazonaws.com`. Pick the region you verified your domain in — credentials are **per region**, so a key made in one region will not authenticate in another:
21
+
22
+ | Region | SMTP endpoint |
23
+ | --- | --- |
24
+ | `us-east-1` (N. Virginia) | `email-smtp.us-east-1.amazonaws.com` |
25
+ | `us-west-2` (Oregon) | `email-smtp.us-west-2.amazonaws.com` |
26
+ | `eu-west-1` (Ireland) | `email-smtp.eu-west-1.amazonaws.com` |
27
+ | `eu-central-1` (Frankfurt) | `email-smtp.eu-central-1.amazonaws.com` |
28
+ | `ap-southeast-2` (Sydney) | `email-smtp.ap-southeast-2.amazonaws.com` |
29
+
30
+ **Not every SES region has an SMTP endpoint.** Cape Town, Hyderabad, Jakarta, Malaysia, Milan, Zurich, Tel Aviv, Bahrain, UAE and Calgary offer the SES API but no SMTP host, so a region that works for the API may not work here — check the [SES endpoints reference](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_smtp_endpoints) before settling on one.
31
+
32
+ Use port 587 (or 25 or 2587) for STARTTLS; 465 and 2465 are implicit TLS, which Spree does not use. SES requires TLS on every connection, so there is no unencrypted option to fall back to.
33
+
34
+ ## Getting SMTP credentials
35
+
36
+ > **WARNING:** **SES SMTP credentials are not your AWS access keys.** As AWS puts it, "Your SMTP password is different from your AWS secret access key." Pasting an IAM secret key into `SMTP_PASSWORD` fails to authenticate — the password is derived from that secret by a signing algorithm that takes the **region** as an input. A password derived for `us-east-1` will not authenticate against `eu-west-1`, which is why credentials cannot be shared between regions. Temporary credentials from STS cannot be used at all.
37
+
38
+ Create them in the console rather than deriving them by hand:
39
+
40
+ 1. Open the SES console and choose **SMTP settings**.
41
+ 2. Choose **Create SMTP Credentials**, which opens IAM and creates a user for sending.
42
+ 3. Reveal the SMTP password, then **Download .csv file**. You cannot view the password again after closing the dialog.
43
+
44
+ Repeat this for each region you send from.
45
+
46
+ ## Authenticating your domain
47
+
48
+ In the SES console, go to **Identities** and create an identity for your domain. SES generates DKIM `CNAME` records to add at your DNS host, and verifying the domain also makes production access easier to obtain. Once verified, set `SMTP_FROM_ADDRESS` to an address on it.
49
+
50
+ Verifying a domain is required regardless of sandbox status: even in production, you must verify every identity used as a From, Source, Sender or Return-Path address.
51
+
52
+ ## Leaving the sandbox
53
+
54
+ Every new SES account starts in the **sandbox**, per region, and the restrictions make a live store impossible:
55
+
56
+ - You can send only **to verified addresses and domains**, so real customers never receive anything.
57
+ - A maximum of **200 recipients per rolling 24-hour period** — a message to several recipients counts once for each of them.
58
+ - A maximum of **1 message per second**.
59
+
60
+ To request production access, open the SES console, go to **Account dashboard**, and choose **Request production access**. You describe your mail as transactional, give your website URL, and confirm you handle bounces and complaints. AWS responds within 24 hours. Verifying your domain first helps the request get approved faster.
61
+
62
+ > **NOTE:** Sending from EC2 adds one more step: EC2 throttles port 25 by default. Using port 587 as shown above avoids it.
63
+
64
+ ## Related
65
+
66
+ - [Emails](../../developer/providers/emails.md) — the SMTP variables and how to verify delivery
67
+ - [Sending out Emails](../../developer/deployment/emails.md) — what Spree sends and when
68
+ - [Deploying Spree on AWS](../../developer/deployment/aws.md)
69
+ - [SES SMTP credentials documentation](https://docs.aws.amazon.com/ses/latest/dg/smtp-credentials.html)
@@ -0,0 +1,51 @@
1
+ ---
2
+ title: Mailgun
3
+ description: Send Spree's transactional emails through Mailgun over SMTP — per-domain credentials, separate US and EU regions, and a sandbox that only emails people you name.
4
+ ---
5
+
6
+ [Mailgun](https://www.mailgun.com) is a long-established email API with flexible routing and a choice of US or EU infrastructure. The EU region makes it a common pick for stores that need their email data to stay in Europe.
7
+
8
+ Spree talks to Mailgun over plain SMTP, so there is nothing to install — see [Emails](../../developer/providers/emails.md) for how the configuration works.
9
+
10
+ ## Configuration
11
+
12
+ ```bash
13
+ SMTP_HOST=smtp.mailgun.org
14
+ SMTP_PORT=587
15
+ SMTP_USERNAME=postmaster@mg.yourstore.com
16
+ SMTP_PASSWORD=your_smtp_password
17
+ SMTP_FROM_ADDRESS=orders@yourstore.com
18
+ ```
19
+
20
+ The username is a full address at your Mailgun sending domain, usually the `postmaster@` mailbox Mailgun creates for you.
21
+
22
+ **Pick the right region.** Mailgun runs the US and EU as separate infrastructure, and an account in one is invisible to the other:
23
+
24
+ | Region | SMTP host |
25
+ | --- | --- |
26
+ | US | `smtp.mailgun.org` |
27
+ | EU | `smtp.eu.mailgun.org` |
28
+
29
+ Mailgun listens on ports 25, 587 and 2525 for STARTTLS, and 465 for implicit TLS, which Spree does not use. Mailgun recommends 587, since some ISPs block or throttle port 25.
30
+
31
+ ## Getting SMTP credentials
32
+
33
+ Credentials are set per domain, not per account:
34
+
35
+ 1. In the Mailgun dashboard, open your sending domain's settings.
36
+ 2. Find its **SMTP credentials**.
37
+ 3. Copy the username, and reset the password to reveal a new one.
38
+
39
+ Because each domain has its own credentials, make sure the ones you use match the domain in `SMTP_FROM_ADDRESS`.
40
+
41
+ ## Authenticating your domain
42
+
43
+ Add your sending domain under **Sending → Domains**. Mailgun asks for TXT records for SPF and DKIM, and CNAME records for tracking. Most setups use a subdomain such as `mg.yourstore.com`, which keeps Mailgun's records away from your main domain's mail. Once the domain verifies, set `SMTP_FROM_ADDRESS` to an address on it.
44
+
45
+ > **WARNING:** **The sandbox domain only emails people you list.** Every new account gets a `sandbox….mailgun.org` domain that can send only to **authorized recipients**, capped at five addresses, each of which must accept an invitation. It is for testing — a store using the sandbox silently fails to reach every customer. Add and verify your own domain, and point `SMTP_HOST`, the credentials and `SMTP_FROM_ADDRESS` at it before taking orders.
46
+
47
+ ## Related
48
+
49
+ - [Emails](../../developer/providers/emails.md) — the SMTP variables and how to verify delivery
50
+ - [Sending out Emails](../../developer/deployment/emails.md) — what Spree sends and when
51
+ - [Mailgun SMTP documentation](https://documentation.mailgun.com/docs/mailgun/user-manual/sending-messages/send-smtp)
@@ -0,0 +1,45 @@
1
+ ---
2
+ title: Postmark
3
+ description: Send Spree's transactional emails through Postmark over SMTP — the Server API Token is both username and password, and transactional mail has its own stream.
4
+ ---
5
+
6
+ [Postmark](https://postmarkapp.com) specialises in transactional email and is known for fast, reliable delivery. It keeps transactional and bulk mail strictly apart, which is a good fit for a store whose email is entirely order confirmations, shipping notices and password resets.
7
+
8
+ Spree talks to Postmark over plain SMTP, so there is nothing to install — see [Emails](../../developer/providers/emails.md) for how the configuration works.
9
+
10
+ ## Configuration
11
+
12
+ ```bash
13
+ SMTP_HOST=smtp.postmarkapp.com
14
+ SMTP_PORT=587
15
+ SMTP_USERNAME=your_server_api_token
16
+ SMTP_PASSWORD=your_server_api_token
17
+ SMTP_FROM_ADDRESS=orders@yourstore.com
18
+ ```
19
+
20
+ > **NOTE:** The **Server API Token goes in both the username and the password field** — the same value twice. This looks like a mistake but is exactly what Postmark documents.
21
+
22
+ Postmark accepts ports 25, 587 and 2525, all using STARTTLS. Use 587 unless your host blocks it, in which case 2525 is the usual fallback. Postmark has **no implicit-TLS port** — setting `SMTP_PORT=465` out of habit produces a connection that hangs rather than a clear error.
23
+
24
+ ## Getting a Server API Token
25
+
26
+ 1. In the Postmark dashboard, open the server you want to send from.
27
+ 2. Go to the **API Tokens** tab and copy the **Server API Token**.
28
+
29
+ Tokens are per server, so mail from each server is tracked and rate-limited separately. A separate server for staging keeps test mail out of your production activity log.
30
+
31
+ ## Message streams
32
+
33
+ Postmark separates **transactional** streams from **broadcast** streams, and keeps their reputations apart. Mail sent through `smtp.postmarkapp.com` with a Server API Token goes to the default transactional stream unless a header says otherwise, which is what a Spree store wants — there is nothing to configure. Broadcast mail uses a different host, `smtp-broadcasts.postmarkapp.com`, which Spree does not need.
34
+
35
+ ## Authenticating your domain
36
+
37
+ Go to **Sender Signatures → Add Domain**, then add the DKIM and Return-Path records Postmark generates at your DNS host. Once verified, set `SMTP_FROM_ADDRESS` to an address on that domain.
38
+
39
+ > **WARNING:** **New Postmark accounts are reviewed before they can send to customers.** Until the account is approved you can only send to domains you have added and verified, which behaves much like a sandbox: real customer addresses are refused. Approval usually takes under a day on weekdays, and only the account owner can request it. Ask as soon as you create the account rather than on launch day, and be ready to describe what your store sends — Postmark enforces its transactional-only policy more strictly than most providers.
40
+
41
+ ## Related
42
+
43
+ - [Emails](../../developer/providers/emails.md) — the SMTP variables and how to verify delivery
44
+ - [Sending out Emails](../../developer/deployment/emails.md) — what Spree sends and when
45
+ - [Postmark SMTP documentation](https://postmarkapp.com/developer/user-guide/send-email-with-smtp)
@@ -0,0 +1,52 @@
1
+ ---
2
+ title: Resend
3
+ description: Send Spree's transactional emails through Resend over SMTP — one hostname, the literal username `resend`, and your API key as the password.
4
+ ---
5
+
6
+ [Resend](https://resend.com) is a transactional email service built for developers, with a deliberately small setup: add a domain, create an API key, and send. It is a good default for a new Spree store that wants working email quickly without a long account review.
7
+
8
+ Spree talks to Resend over plain SMTP, so there is nothing to install — see [Emails](../../developer/providers/emails.md) for how the configuration works.
9
+
10
+ ## Configuration
11
+
12
+ ```bash
13
+ SMTP_HOST=smtp.resend.com
14
+ SMTP_PORT=587
15
+ SMTP_USERNAME=resend
16
+ SMTP_PASSWORD=re_your_api_key
17
+ SMTP_FROM_ADDRESS=orders@yourstore.com
18
+ ```
19
+
20
+ The username is the **literal string `resend`** — not your email address and not the API key. The API key goes in the password field.
21
+
22
+ Resend also accepts ports 25 and 2587 for STARTTLS. Ports 465 and 2465 are implicit TLS, which Spree does not use, so stay on 587.
23
+
24
+ ## Getting an API key
25
+
26
+ 1. Open the Resend dashboard and go to **API Keys**.
27
+ 2. Create a key with sending permission.
28
+ 3. Copy it immediately — the full value is shown only once. Keys start with `re_`.
29
+
30
+ ## Authenticating your domain
31
+
32
+ Go to **Domains → Add Domain**, enter your sending domain, and add the records Resend generates at your DNS host:
33
+
34
+ - **DKIM**, which proves the mail is really yours.
35
+ - **SPF**, plus a record on the sending subdomain that routes bounces back to Resend.
36
+
37
+ Create each one with the **type Resend displays**. Older domains are given `TXT`
38
+ and `MX` records for SPF, where domains added after August 2026 may get `CNAME`
39
+ records instead — so copy what the dashboard shows rather than assuming a type.
40
+ On older domains both SPF records must be right or SPF does not verify at all.
41
+
42
+ Once the domain shows as verified, set `SMTP_FROM_ADDRESS` to an address on it. A verified domain already passes SPF and DKIM; **DMARC** is not needed to verify, but is worth adding afterwards.
43
+
44
+ > **WARNING:** **Until you verify a domain, you can only email yourself.** An unverified account sends from `onboarding@resend.dev`, and Resend restricts that test sender to the address on your own Resend account — anything else is refused with "You can only send testing emails to your own email address". A store in this state appears to work while no customer ever receives an order confirmation, so verify your domain before going live.
45
+
46
+ > **NOTE:** Resend's free tier allows 3,000 emails a month but also caps sending at **100 a day**. A busy day of confirmations and shipping notices can reach that ceiling well before the monthly allowance, so check the daily figure rather than the monthly one when sizing a plan.
47
+
48
+ ## Related
49
+
50
+ - [Emails](../../developer/providers/emails.md) — the SMTP variables and how to verify delivery
51
+ - [Sending out Emails](../../developer/deployment/emails.md) — what Spree sends and when
52
+ - [Resend SMTP documentation](https://resend.com/docs/send-with-smtp)
@@ -0,0 +1,44 @@
1
+ ---
2
+ title: SendGrid
3
+ description: Send Spree's transactional emails through Twilio SendGrid over SMTP — the username is always the literal string `apikey`, with your API key as the password.
4
+ ---
5
+
6
+ [Twilio SendGrid](https://sendgrid.com) is one of the longest-established email platforms, built for high volume with detailed analytics and a mature deliverability toolset. It suits stores already sending a lot of mail, or teams that want SendGrid's reporting alongside its API.
7
+
8
+ Spree talks to SendGrid over plain SMTP, so there is nothing to install — see [Emails](../../developer/providers/emails.md) for how the configuration works.
9
+
10
+ ## Configuration
11
+
12
+ ```bash
13
+ SMTP_HOST=smtp.sendgrid.net
14
+ SMTP_PORT=587
15
+ SMTP_USERNAME=apikey
16
+ SMTP_PASSWORD=SG.your_api_key
17
+ SMTP_FROM_ADDRESS=orders@yourstore.com
18
+ ```
19
+
20
+ > **NOTE:** The username is the **literal string `apikey`**, exactly as written above — not your SendGrid username, and not the key itself. SendGrid's own wording: "This setting is the exact string `apikey` and not the API key itself." Your API key goes in the password field, used as-is: the Base64 encoding SendGrid mentions elsewhere applies to testing by hand with `openssl`, not to an application connecting over SMTP.
21
+
22
+ SendGrid recommends port 587, which avoids the rate limiting and connection blocking some ISPs and hosting providers apply to port 25.
23
+
24
+ ## Getting an API key
25
+
26
+ 1. In the SendGrid dashboard go to **Settings → API Keys** and choose **Create API Key**.
27
+ 2. Give it **Mail Send** permission — that is all Spree needs, and a restricted key limits the damage if it leaks.
28
+ 3. Copy the key immediately; it is shown only once.
29
+
30
+ ## Authenticating your domain
31
+
32
+ Go to **Settings → Sender Authentication** and complete **Domain Authentication**. SendGrid generates CNAME records to add at your DNS host, covering DKIM signing and the return path. Once verified, set `SMTP_FROM_ADDRESS` to an address on that domain.
33
+
34
+ > **WARNING:** SendGrid rejects mail from senders it cannot verify. Authenticating the whole domain is the right choice for a store, because every address on it can then send. Single Sender Verification exists for one-off addresses, but it does not scale to a store's From, reply-to and notification addresses.
35
+
36
+ ## Account plans
37
+
38
+ SendGrid **retired its free plans in 2025**. New accounts now start on a 60-day trial that allows up to 100 emails per day, and when the trial ends any integration using the account's API keys stops sending until you move to a paid plan. Plan for a paid plan before launch rather than discovering the cutoff when order confirmations stop.
39
+
40
+ ## Related
41
+
42
+ - [Emails](../../developer/providers/emails.md) — the SMTP variables and how to verify delivery
43
+ - [Sending out Emails](../../developer/deployment/emails.md) — what Spree sends and when
44
+ - [SendGrid SMTP documentation](https://www.twilio.com/docs/sendgrid/for-developers/sending-email/getting-started-smtp)
@@ -39,6 +39,18 @@ Paying sellers, rather than taking money from shoppers. See [Seller payouts](../
39
39
  - [Meilisearch](search/meilisearch.md) — One platform to build, scale, and unify search and AI retrieval. Search-as-you-type returns answers in less than 50 milliseconds. That's faster than the blink of an eye!
40
40
 
41
41
 
42
+ ## Emails
43
+
44
+ Spree sends transactional email over plain SMTP, so any provider works with the same environment variables. See [Emails](../developer/providers/emails.md) for the configuration and how to choose between them.
45
+
46
+
47
+ - [Resend](email/resend.md) — Developer-focused transactional email with a fast setup — add a domain, create an API key, and send.
48
+ - [Postmark](email/postmark.md) — Built specifically for transactional email, keeping order and account mail apart from bulk sending.
49
+ - [SendGrid](email/sendgrid.md) — A long-established platform for high volume, with detailed analytics and deliverability tooling.
50
+ - [Mailgun](email/mailgun.md) — Flexible routing with a choice of US or EU infrastructure for stores that keep email data in Europe.
51
+ - [Amazon SES](email/amazon-ses.md) — The cheapest option at volume, and the natural fit for a store already running on AWS.
52
+
53
+
42
54
  ## Analytics
43
55
 
44
56
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@spree/docs",
3
- "version": "0.1.268",
3
+ "version": "0.1.270",
4
4
  "description": "Spree Commerce developer documentation for AI agents and local reference",
5
5
  "type": "module",
6
6
  "license": "CC-BY-4.0",