remove the CARD.FUNDING_SOURCE_CHANGE webhook from the spec

.claude/skills/grid-api/references/endpoints.md

@@ -332,7 +332,6 @@ Drive card lifecycle events in sandbox to test authorization, clearing, and retu
 - `verification-update`: Verification status change
 - `agent-action`: Agent action requires approval or changed status
 - `card-state-change`: Card state changed
-- `card-funding-source-change`: Card funding source changed
 - `card-transaction`: Card transaction event
 - `bulk-upload`: Bulk job completion
 - `invitation-claimed`: Invitation claimed

.stainless/stainless.yml

@@ -1028,7 +1028,7 @@ openapi:
       reason: >-
         Remove the wide WebhookType $ref from BaseWebhook so the inline
         single-value enums on each child webhook (e.g. CardStateChangeWebhook,
-        CardFundingSourceChangeWebhook) become the sole definition. Without
+        CardTransactionWebhook) become the sole definition. Without
         this, every generated *WebhookEvent has the full WebhookType enum on
         its `type` field, so the UnwrapWebhookEvent deserializer can't
         discriminate between variants that share a `data` shape (Card) and

mintlify/snippets/cards/funding-sources.mdx

@@ -55,9 +55,6 @@ curl -X PATCH "$GRID_BASE_URL/cards/Card:019542f5-b3e7-1d02-0000-000000000010" \
 The same flow covers `state`, `fundingSources`, or both fields supplied
 together.
 
-`CARD.FUNDING_SOURCE_CHANGE` fires on every successful update with the
-post-change `Card` resource.
-
 ### Errors
 
 | Status | Code | What it means |

mintlify/snippets/cards/implementation-overview.mdx

@@ -15,10 +15,10 @@ cards. Cards do not require new webhook endpoints or new API
 credentials — they reuse what's already configured for the rest of
 Grid. You'll only need to:
 
-- Subscribe to the new card-specific webhook types (`CARD.STATE_CHANGE`
-  and `CARD.FUNDING_SOURCE_CHANGE`). Card-transaction lifecycle events
-  ride on the generic transaction webhook stream that already covers
-  outgoing-payment activity.
+- Subscribe to the card webhook types: `CARD.STATE_CHANGE` for card
+  state, and `CARD_TRANSACTION.AUTHORIZED`,
+  `CARD_TRANSACTION.PARTIALLY_SETTLED`, `CARD_TRANSACTION.SETTLED`, and
+  `CARD_TRANSACTION.EXCEPTION` for the transaction lifecycle.
 - Confirm with your Lightspark contact that cards are enabled for your
   platform — issuance requires an issuer-side onboarding.
 - If your program includes physical cards, start the artwork early:
@@ -93,10 +93,9 @@ When you're ready to go live:
 
 - Complete card-issuer onboarding through your Lightspark contact.
 - Confirm webhook security, monitoring, and alerting cover the
-  `CARD.*` event types plus card-destination transactions on the
-  generic transaction webhook stream.
-- Build the `EXCEPTION` dashboard view from card-destination
-  transaction webhooks (filter by `status: "EXCEPTION"`) and wire it
+  `CARD.*` and `CARD_TRANSACTION.*` event types.
+- Build the `EXCEPTION` dashboard view from `CARD_TRANSACTION.EXCEPTION`
+  webhooks and wire it
   into on-call alerting.
 
 <Check>

mintlify/snippets/cards/reconciliation.mdx

@@ -37,10 +37,8 @@ A merchant `RETURN` does not move the status. The transaction stays
 | `SETTLED` | All clearings for the auth have posted. The transaction is closed against the funding source. A `RETURN` received afterwards keeps it `SETTLED` with the returned value in `refundedAmount`. |
 | `EXCEPTION` | The transaction settled to the network but the corresponding pull from the funding source failed. |
 
-Every transition is delivered via the generic transaction webhook
-stream carrying the post-change parent (a follow-up extends the
-Transaction model with a card destination type — see
-[Webhooks](/cards/platform-tools/webhooks)).
+Every transition is delivered as a `CARD_TRANSACTION.*` webhook carrying
+the post-change parent — see [Webhooks](/cards/platform-tools/webhooks).
 
 ## The over-auth path
 

mintlify/snippets/cards/sandbox-testing.mdx

@@ -139,7 +139,6 @@ curl -X POST "$GRID_BASE_URL/sandbox/cards/Card:.../simulate/return" \
   -d '{ "cardTransactionId": "CardTransaction:...", "amount": 1500 }'
 ```
 
-At each step you'll see `CARD.STATE_CHANGE` or
-`CARD.FUNDING_SOURCE_CHANGE` webhooks plus transaction webhooks for
-the simulated authorization, clearing, and return — wire those into
+At each step you'll see `CARD.STATE_CHANGE` webhooks plus transaction
+webhooks for the simulated authorization, clearing, and return — wire those into
 your local webhook handler to validate end-to-end.

mintlify/snippets/cards/webhooks.mdx

@@ -1,21 +1,23 @@
-Cards add two webhook event types on top of Grid's existing webhook
+Cards add five webhook event types on top of Grid's existing webhook
 infrastructure. Signature verification (`X-Grid-Signature`) and
 retry behavior are identical to the rest of Grid — see
 [Authentication](/api-reference/authentication) and
 [Webhooks](/api-reference/webhooks) for the underlying mechanics.
 
-Card-transaction lifecycle events are not card-specific webhooks —
-they ride on the generic transaction webhook stream (a follow-up
-extends the Transaction model with a card destination type).
+One covers the card itself; the other four cover a card transaction's
+lifecycle.
 
 ## Event types
 
 | Type | Fires on |
 |------|----------|
 | `CARD.STATE_CHANGE` | `PROCESSING → ACTIVE`, `→ CLOSED (ISSUER_REJECTED)`, and every subsequent `ACTIVE ⇄ FROZEN` and `→ CLOSED` transition. |
-| `CARD.FUNDING_SOURCE_CHANGE` | Whenever `PATCH /cards/{id}` updates the `fundingSources` array. |
+| `CARD_TRANSACTION.AUTHORIZED` | An authorization is approved and a hold is placed on the funding source. |
+| `CARD_TRANSACTION.PARTIALLY_SETTLED` | A clearing posted, but more are still expected. |
+| `CARD_TRANSACTION.SETTLED` | All clearings have posted. Re-fires when a merchant return lands, with the returned value in `refundedAmount`. |
+| `CARD_TRANSACTION.EXCEPTION` | The transaction settled to the network but the pull from the funding source failed. |
 
-All three carry the standard envelope:
+All of them carry the standard envelope:
 
 ```json
 {
@@ -73,20 +75,13 @@ Common branches to handle in your consumer:
 - `state: "CLOSED"`, `stateReason: "CLOSED_BY_PLATFORM"` — close
   confirmed; stop showing the card.
 
-## CARD.FUNDING_SOURCE_CHANGE
-
-Fires whenever a `PATCH /cards/{id}` call changes the `fundingSources`
-array. The `data` payload is the full `Card` resource with the
-post-change `fundingSources`, so a consumer that only cares about the
-current set of bindings can replace state wholesale.
-
 ## Card-transaction lifecycle
 
-Authorization, pull, clearing, refund, and `EXCEPTION` transitions are
-not delivered through a dedicated card webhook. They flow through
-the generic transaction webhook stream that already carries
-outgoing-payment lifecycle events; a follow-up PR adds the card
-destination type to that stream. See
+Each `CARD_TRANSACTION.*` event carries the full `CardTransaction`
+resource. Not every delivery changes `status`: a merchant return has no
+event type of its own and re-fires `CARD_TRANSACTION.SETTLED` with the
+same status, so treat a repeated `SETTLED` as a new update and read
+`refundedAmount` to tell it apart from the original settlement. See
 [Reconciliation](/cards/transactions/reconciliation) for the
 underlying event model.
 

openapi/components/schemas/webhooks/WebhookType.yaml

@@ -37,7 +37,6 @@ enum:
   - BULK_UPLOAD.FAILED
   - AGENT_ACTION.PENDING_APPROVAL
   - CARD.STATE_CHANGE
-  - CARD.FUNDING_SOURCE_CHANGE
   - CARD_TRANSACTION.AUTHORIZED
   - CARD_TRANSACTION.PARTIALLY_SETTLED
   - CARD_TRANSACTION.SETTLED