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-08-24 ​

  • Agreement set bumped to 2026-08-24.1. Formatting-only fix to the International Card Terms: the fees block (foreign purchase and penalty fees) now renders as regular text instead of a raw code block. No terms, fees, or rights changed. 2026-08-21.1, 2026-07-26.1, and 2026-07-24.1 all stay accepted, so no partner is forced to change. If you present the international terms, re-fetch the canonical document and recompute its sha256 at your next convenient change.

2026-08-21 ​

  • Agreement set bumped to 2026-08-21.1. The International Card Terms (card-terms-international) gain section 8.4, Cardholders in Nigeria: BANEX MICROFINANCE BANK LIMITED, licensed by the Central Bank of Nigeria, markets the card and owns CBN and Nigeria Data Protection Act compliance, while Agio handles customer service. No other document changed. 2026-07-26.1 and 2026-07-24.1 stay accepted, so no partner is forced to change. If you present the international terms, re-fetch the canonical document and recompute its sha256. See Consent attestation.

2026-08-14 ​

  • Card name fields validated before the issuer call. createCard now rejects invalid displayName and shipping.firstName / shipping.lastName values with a VALIDATION_ERROR naming the field, the allowed pattern, and the offending characters, replacing the generic CARD_API_ERROR. displayName matches ^[a-zA-Z0-9 .-]+$ (max 26 characters); shipping names match ^[a-zA-Z -]+$ (max 50). Accented and non-Latin characters are rejected: transliterate to ASCII ("Renée" becomes "Renee") before submitting. No card is created on a validation failure, so a corrected retry is always safe. See the error reference.

2026-08-04 ​

  • card_application.status_changed gains nextStep and reasonDescription. Both are optional and additive, so a receiver that ignores them behaves as before. nextStep is RESUBMIT, AWAIT_REVIEW, TERMINAL, or null, and tells you whether the cardholder can correct and retry, whether a decision is still pending, or whether the outcome is final. reasonDescription carries a reviewer comment when one is present, which is uncommon, so do not depend on it being populated. See the updated delivery shape.

2026-07-29 ​

  • Agreement set bumped to 2026-07-26.1. The only change is Agio's registered office address, now 45 West Bay Street, Manx Corporate Centre, 4th floor, Nassau, New Providence, The Bahamas. It affects card-terms-us, privacy-policy, and terms-of-use. No terms, fees, or rights changed. 2026-07-24.1 is still accepted, so partners on it need no change. Going forward, the previous agreement version stays accepted alongside each new one, so a version bump will not break an in-flight integration.

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.