Pawsitive Future Pawsitive FutureDeveloper docs

post_donations_session_by_id_donor_email

Changes data · you confirm first

Calls POST /api/donations/session/{id}/donor-email as the signed-in person · REST reference

Correct, once, the email the gift of a Checkout session was recorded under

PUBLIC, with the Checkout session id as the bearer token, under the same paid-and-7-days rule as GET /api/donations/session/{id}/receipt, and SINGLE-USE: once a gift has been corrected, every later call carrying a different address answers 409 ALREADY_CORRECTED. "Corrected" is the audit row the correction wrote for the donation, decided under the donation's lock, so it survives restarts and two concurrent calls cannot both succeed. In order: rewrites the donor email on the donation, on every recurring cycle charged from it and on their certificates (one DAL transaction; the audit row keeps the old and new address); re-renders the receipt with the corrected address and emails it there; then writes the address into Stripe's record of the gift, one-time or recurring alike — the PaymentIntent's metadata.donor_email, the Charge's receipt_email and metadata.donor_email, and the Customer's email when the session or PaymentIntent names one. A refused Stripe write answers 502 after the graph and the receipt are done, and every Stripe attempt is audited with what Stripe answered (donation.donor_email.stripe_updated, SUCCESS or FAILURE). A replay with exactly the address on record is the retry for that 502: it changes nothing in the graph, sends no second receipt, and writes the same values to Stripe again. The PaymentIntent's own receipt_email and the Checkout Session's customer_email stay as typed — Stripe does not let either change after payment. Future recurring charges inherit the corrected address.

Arguments

ArgumentTypeDescription
idpathstringrequiredStripe Checkout session id (cs_...).
bodyJSONobjectrequiredThe request body, as a JSON object. Its fields are listed below.

Fields of body

FieldTypeDescription
emailstringrequiredThe corrected address. Trimmed; same shape rule as create-checkout-session.

Example call

A client sends this over the MCP session; Claude and other agents build it for you. The values are placeholders — the shape is real.

json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "post_donations_session_by_id_donor_email",
    "arguments": {
      "id": "string",
      "body": {
        "email": "string"
      }
    }
  }
}
Confirmation
The client shows the person the exact request and waits. Nothing runs until they tick Make this change. See Reading and changing.

Result

On success (HTTP 200) the tool returns one text item holding the API's JSON, pretty-printed.

The address now on record. The receipt has been sent to it, and Stripe's record of the gift carries it.

json
{
  "email": "string"
}

Fields

FieldTypeDescription
emailstring

When it fails

A failed call returns isError: true with the API's message as text. A change the person declines, or lets time out, also comes back this way and nothing changes.

400

Not an email address.

404

Unknown, unpaid or expired session, or a fully anonymous gift, which records no donor.

409

code: ALREADY_CORRECTED — this gift's one correction has been used; final, nothing was changed. code: NOT_YET_RECORDED — the webhook has not recorded the session's donation yet; ask again shortly.

502

Stripe answered, and answered badly — reading the session, or writing the corrected address to Stripe's record of the gift. In the second case the graph and the receipt already carry the address; sending the same address again retries the Stripe writes.

What the model is shown

This is the tool exactly as the server lists it in tools/list. The description starts with the REST call it makes.

json
{
  "name": "post_donations_session_by_id_donor_email",
  "description": "POST /api/donations/session/{id}/donor-email — PUBLIC, with the Checkout session id as the bearer token, under the same paid-and-7-days rule as `GET /api/donations/session/{id}/receipt`, and SINGLE-USE: once a gift has been corrected, every later call carrying a different address answers 409 `ALREADY_CORRECTED`. \"Corrected\" is the audit row the correction wrote for the donation, decided under the donation's lock, so it survives restarts and two concurrent calls cannot both succeed. In order: rewrites the donor email on the donation, on every recurring cycle charged from it and on their certificates (one DAL transaction; the audit row keeps the old and new address); re-renders the receipt with the corrected address and emails it there; then writes the address into Stripe's record of the gift, one-time or recurring alike — the PaymentIntent's `metadata.donor_email`, the Charge's `receipt_email` and `metadata.donor_email`, and the Customer's `email` when the session or PaymentIntent names one. A refused Stripe write answers 502 after the graph and the receipt are done, and every Stripe attempt is audited with what Stripe answered (`donation.donor_email.stripe_updated`, SUCCESS or FAILURE). A replay with exactly the address on record is the retry for that 502: it changes nothing in the graph, sends no second receipt, and writes the same values to Stripe again. The PaymentIntent's own `receipt_email` and the Checkout Session's `customer_email` stay as typed — Stripe does not let either change after payment. Future recurring charges inherit the corrected address.\n\nThis changes data. The person is asked to confirm it before it runs, and nothing happens if they decline.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "id": {
        "type": "string",
        "description": "Stripe Checkout session id (cs_...)."
      },
      "body": {
        "type": "string",
        "description": "The JSON request body: { email*: string (The corrected address.) }"
      }
    },
    "required": [
      "id",
      "body"
    ]
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true,
    "idempotentHint": false,
    "openWorldHint": false
  }
}