Agio Developer

Appearance

On this page

Partner Card API Changelog ​

Release notes for the Partner Card API. Dates reflect production availability at api.agiodigital.com/partner/cards/graphql. Changes land on the development environment (dev.api.agiodigital.com) first — test there before relying on new capabilities in production.

2026-07-24 ​

  • Reference table for all agreement documents separated from the selection guide. The full document list (all program types) is now its own labeled reference section, distinct from the per-residency selection table. See Consent attestation.
  • Agreement selection clarified. The document list is a catalog, not a cumulative set. US cardholders accept the US Card Terms and US Account Opening Privacy Notice; non-US cardholders accept the International Card Terms. card_company_id does not change the application type. See Consent attestation.

2026-07-20 ​

  • Canonical agreement documents published for hashing. Each document in agreementsAcceptance.documentHashes is now served as raw markdown at its own https://www.agiodigital.com/<slug>.md URL. Fetch the document and SHA-256 its bytes to produce the sha256 you relay — the guide lists the documentHashes key → URL mapping. See Consent attestation.

2026-07-17 ​

  • Consent attestation added to createCardApplicationForPartnerUser. New agreementsAcceptance input relays verifiable evidence of cardholder consent (agreement version, document hashes, acceptance timestamp). From 2026-07-20 this field is required — omitting it returns errorCode: "ATTESTATION_REQUIRED"; invalid evidence fails with a validation error. isTermsOfServiceAccepted remains for backward compatibility but is now legacy. See Consent attestation.

2026-07-13 ​

  • payment events now carry postedAt. card_transaction.* deliveries and AgioCard_card_transaction rows with transactionType: "payment" now populate postedAt on posting; it previously shipped null on every payment row. Historical rows were backfilled from the original webhook payload where the processor had already reported a posted date.
  • cardCompanyId now derived for partner cardholders on all transaction events. card_transaction.* deliveries for partner-cardholder cards now carry a populated cardCompanyId (previously null outside fee rows), derived server-side from the cardholder's card_user/card_application linkage. Historical rows were backfilled the same way. See the updated delivery shape example.
  • Field-availability matrix added. The guide now documents which data fields are populated per transactionType (spend/collateral/payment/fee), including which fields are null by design — see Field availability by transaction type.
  • Collateral and payment event semantics explained. New guide section covering how collateral events originate (your funding and withdrawals — the sign of amount is the direction), how payment events settle accrued card spend automatically from the cardholder's collateral, and the one-balance-many-cards model behind both — see Understanding collateral and payment events.
  • Webhook starter kit updated for per-type card linkage. The starter kit README and demo receiver now reflect that card linkage is spend-only: wallet-level events (collateral/payment) are matched via cardUserId/cardCompanyId, per the field-availability matrix.

2026-07-10 ​

  • New patchPartnerCardUser mutation. Correct a cardholder's PII — including any address field — at any point before an application is submitted. Only the fields you supply change; the address is re-validated as a merged set. See Correct a cardholder before applying.
  • Earlier, clearer onboarding validation. createPartnerCardUser now validates required fields on submission — blank values and malformed country codes return VALIDATION_ERROR naming each field in a single response — and createCardApplicationForPartnerUser returns INCOMPLETE_ADDRESS listing any missing address fields, so issues surface before the application call. See the error reference.
  • Active-card limit documented. The guide now states the per-cardholder active-card limit (3 active cards within a rolling 90-day window on the developer tier) and the error returned when it's reached. See Active-card limit.

2026-07-09 ​

  • Card transaction webhook payload fixed and enriched. card_transaction.* deliveries previously shipped cardId, externalId, and occurredAt as always-null; those fields are replaced by correctly-populated identifiers (cardId, cardExternalId, cardTransactionExternalId, cardUserId, webhookEventId) and the payload now carries the full transaction record — merchant name/location/category, original amount and currency (localAmount/localCurrency, integer minor units), authorizedAt/postedAt, and more — so a delivery is self-sufficient with no follow-up API call. Deliveries now match what your API token can query on AgioCard_card_transaction. See the updated delivery shape.
  • Webhook starter kit updated. The starter kit receiver now demonstrates per-event routing for card_transaction.* events.

2026-07-06 ​

  • createCard reliability in production. The card-program product configuration is now always applied server-side, resolving intermittent createCard failures (body is missing required property 'configuration'). No change is required on your side — continue sending cardApplicationId and cardType as documented.

2026-07-01 ​

  • Card transaction webhooks are live. subscribePartnerWebhook now delivers real-time transaction events alongside application events: CARD_TRANSACTION_AUTHORIZED, CARD_TRANSACTION_SETTLED, CARD_TRANSACTION_DECLINED, and CARD_TRANSACTION_REVERSED. Subscription setup, payload shapes, and signature verification are documented under Webhook subscriptions.
  • Card dispute management. New cancelCardDispute mutation plus dispute lifecycle webhook events for partner-organization cards.
  • Rate limits documented. The guide now includes the full rate-limit reference.

2026-06-19 ​

  • Treasury funding and withdrawals. Partner organizations can fund card programs and withdraw collateral via the API; the new cardFundSubClientStatus query reports sub-client funding status. See Funding cards and Withdrawing collateral.

2026-06-18 ​

  • Batch distributions. New partnerMultisend mutation distributes funds to many cardholders in one call, with smart-wallet lookup support. See Multisend.

2026-06-01 ​

  • Webhook endpoint requirements clarified. Receiving URLs must be publicly reachable; the webhook onboarding guide was expanded accordingly.

2026-05-29 ​

  • Webhook starter kit. Downloadable starter kit with Express and Bun receiver templates, plus a registry of all subscribable event types.

2026-05-26 ​

  • Onboarding additions. createCardApplicationForPartnerUser accepts partnerKycShareToken (share an existing KYC verification) and a createWallet flag to provision a wallet at card signup. Do not pass an organization ID when provisioning cardholders — it is derived from your API client automatically.

2026-05-19 ​

  • Initial general availability of the Partner Card API: HMAC-signed GraphQL endpoint, cardholder onboarding (KYC + application), virtual card issuance, and application webhooks. Start with the Quickstart.

2026-05-15 ​

  • Application tracking. Card application responses now include cardApplicationId for tracking an application through review.