Three updates this month across physical card operations, API integration management, and card shipping. All three are live. If any of these touch areas you've been managing around, it's worth a conversation with your account team.
1. Physical Card Restock: From Manual Coordination to Managed Process
Running a physical card program means managing inventory. And until now, that meant your team tracking down the right person at Reap, communicating requirements over email, and waiting with limited visibility on where things stood.
As card volumes grow, that approach doesn't scale. Restock lead times for physical cards range from four weeks for standard PVC to six to eight weeks for metal — which means a delayed or missed request isn't just an inconvenience, it can result in a stock-out that directly blocks new cardholder issuance.
We've launched a dedicated restock submission form that formalizes this process end-to-end. When your team submits a request, it automatically logs in our operations tracker, raises a Zendesk ticket with Card Ops, and generates a draft communication to the card manufacturer, all from a single submission.
No more coordinating across channels or wondering whether your request was received.
What this means for your program
For clients operating at any meaningful card volume, this change removes a real operational risk. Every restock request now has a clear paper trail from the moment it's submitted, which means your team and ours are always working from the same record. The process is also consistent regardless of who initiates it on your side; whether that's an ops lead, a CSM, or someone covering during a handover.
Who this affects: Any client issuing physical cards (PVC, Smart Prime, or Metal).
What to do: If you're approaching your reorder threshold or haven't submitted a restock recently, now is the time to use the new flow. If you're unsure what your current inventory position looks like or want to walk through the process, reach out to your account team — we're happy to do that with you.
2. Webhook Management: Full Lifecycle Control Is Now in Your Hands
Webhooks are the backbone of any real-time card integration. They're how your systems receive authorization decisions, transaction events, card status updates, and more, without polling. The more you build on the CaaS API, the more endpoint configurations you accumulate: UAT versus production environments, event-specific setups, endpoints tied to services you've since deprecated.
Until this update, the CaaS API only supported POST /webhooks. You could register endpoints, but had no self-serve way to see what was active or remove what you no longer needed. Decommissioning a web-hook required raising a support request with Reap, creatin unnecessary friction for something that could have been routine integration maintenance.
What's changed
Two new endpoints are now live, accessible via both the API and the Developer Settings section of your dashboard:
GET /webhooks — returns a full list of registered web-hook endpoints for your account, including endpoint URLs, event subscriptions, and status. Use this to audit your integration configuration without contacting Reap.
DELETE /webhooks/{id} — removes a web-hook endpoint you no longer need. Use this to clean up stale endpoints, decommission configurations tied to deprecated services, or tidy up after environment changes.
What this unlocks
Your engineering team can now manage the full lifecycle of your web-hook setup independently; (1) creating, (2) auditing, and (3) decommissioning endpoints, without any dependency on Reap support.
That's a meaningful improvement in integration self-sufficiency, and it matters particularly for security hygiene: you can promptly retire endpoints when rotating services or off-boarding team members, rather than waiting on manual removal.
This also brings us to feature parity with what industry-standard issuing API providers offer as table stakes. Full CRUD web-hook management is a baseline expectation for a production-grade integration, and it's now available.
What's coming next
Webhook re-triggering is in development. This will let your team search for specific web-hook events and re-trigger delivery directly from the dashboard, useful for debugging missed deliveries or replaying transactions without escalating to Reap engineering. We'll announce when it's live.
What to do: If your integration has been running for some time, this is a good moment to audit what's registered. Navigate to Developer Settings on your dashboard, or call GET /webhooks via the API, and review your active endpoints. If anything looks stale or unfamiliar, clean it up now. If you'd like a hand reviewing your configuration, your account team can walk through it with you.
3. ZONE Field Now Required for Shipments to CA, US, IN, MX, and AE — Action Required
This is a breaking change if you're shipping physical cards to Canada, the United States, India, Mexico, or the United Arab Emirates. If those markets are in scope for your program, read this section carefully and check your integration before your next shipment.
What's changed
The ZONE field, which carries the state or province code for the delivery address, is now required when calling POST /cards/{cardId}/ship (Direct Ship) or POST /cards/bulk-ship (Bulk Ship) for those five countries.
Requests submitted without a valid ZONE value for those markets will return the following error and will not be processed:
Invalid zone code {zone code} for {country code}. Please provide a valid province/state code.
For all other shipping destinations, ZONE remains optional and your existing integration is unaffected.
Why we're enforcing this
Shipping address data without a valid state or province code is routinely rejected by logistics providers in these markets, where it's required for routing. When that happens, it triggers manual intervention by Reap's logistics team to resolve the shipment before it can proceed, which delays card delivery to your cardholders. As shipment volumes scale, that manual intervention is a bottleneck that can't be absorbed indefinitely.
Enforcing the field at the API layer means address data is complete before it reaches the fulfillment layer: fewer rejected shipments, faster delivery, and a better experience for cardholders waiting on their card. This is also aligned with the stricter address validation requirements of Thales, our new fulfillment provider.
Who this affects
Any client shipping physical cards to CA, US, IN, MX, or AE via Direct Ship or Bulk Ship. If your active shipping destinations don't include those five markets, this change does not affect your integration.
What you need to do
Check whether your integration includes the ZONE field for shipments to the affected countries. If it doesn't, update it before your next shipment.
State and province codes follow standard ISO 3166-2 format — for example, CA for California, ON for Ontario, DU for Dubai. If you want to validate your implementation or run through a test shipment, reach out to your account team and we can set that up.
→ Direct Ship API reference | Bulk Ship API reference
