This release introduces full lifecycle management for custom fields and options, adds support for SELECT field types, and extends card request APIs and webhooks with customFields capabilities.

Details

• Custom Field Management Endpoints New endpoints to manage custom fields and their options:

  • Create, update, and delete custom fields
  • List, create, update, and delete custom field options

• Callbacks Added callback support for:

  • Custom Fields
  • Custom Field Options

• New Field Type Support Added support for custom fields of type SELECT in the CaaS/Pro API layer for:

  • Cards
  • Accounting transactions

• Card Request Enhancements Added support for custom fields (independent of text) in:

  • Card Request endpoints
  • Card Request webhook

We've introduced the Card Copilot feature, enabling organizations to share travel purchasing card access with multiple users. Copilots have full card privileges including viewing details, managing settings, and making transactions.

What's New

• Card Sharing: Grant full card access to users beyond the original cardholder
• Team Support: Assign entire teams as copilots for shared departmental cards
• Audit Trail: All copilot activities are tracked for compliance and security
• Seamless Transfers: Transfer card ownership between copilots when needed

Getting Started

1. Enable: Activate the module via Modules page (owner/admin only)
2. Assign: Add copilots when issuing cards using the copilots parameter in Issue Card endpoints
3. Manage: Update copilots anytime via Update Card Copilots
4. Transfer: Allow copilots to claim cards using Claim Card As Copilot

API Updates

• Issue Card endpoints now accept the copilots parameter with cardholderIds and/or teamIds
• New endpoints:
  • Update Card Copilots
  • Claim Card As Copilot

📘

Note

This feature is exclusive to Travel Purchasing Cards and requires Module activation

What changed?
We’ve updated the expected audience value used when authenticating with our API on the sandbox environment.

Previous value:
audience: api.staging.v2.infinnitytest.com/api/integration

New value:
audience: api.staging.infinnitytest.com/api/integration

Impact:
Make sure your token’s audience claim now matches the updated value above. This change ensures proper validation against our sandbox environment.

Reference:
Authenticated API Usage – Pliant Partner Docs

❗️

This change applies only to sandbox environments and does not affect production.

We've introduced two new card limit renewal frequency options that can be used when issuing cards:

• DAILY - Card limits reset on a daily basis
• WEEKLY - Card limits reset on a weekly basis

Example Usage

When creating a card, you can now specify:

{
  "limitRenewFrequency": "DAILY"
}

or

{
  "limitRenewFrequency": "WEEKLY"
}

Backwards Compatibility

This change is fully backwards compatible. Existing card limit renewal frequencies remain unchanged and continue to function as before.

We have added the cardAccountId property to the following event types:

Cards

CARD_CREATED
CARD_ISSUED
CARD_DETAILS_CHANGED
CARD_STATUS_CHANGED

Transactions

TRANSACTION_CREATED
TRANSACTION_UPDATED

Statements

STATEMENT_GENERATED
STATEMENT_UPDATED

We introduced two new endpoints.

Deactivate Organization Authorization

This endpoint completes the existing "Activate Organization Authorization" and will enable you to reset and organization authorization when needed.

Redeem Cashback

The following endpoint will enable a specific organization to redeem the accumulated cashback (totally or partially), completing the "cashback flow" together with the existing endpoints.

We have added further type<>status combinations for our mock service in the sandbox environment. Changes visible here.

We have made small improvements to the transaction, statements and card account entities.

Set receiptNeeded flag on on transaction level

We have added an endpoint that allows to manage the necessity to provide receipts within the Pliant platform (web apps, mobile app). Its now possible to turn receiptNeeded property to false on transaction level allowing for some automations based on e.g. card or merchant level. As API consumer you can now turn off receipts for specific merchants or cards. The endpoint is documented here: PATCH /transactions/{{transactionId}}/receiptUpload.

Balance for each card account

Previously the balance property has been only available on organization level. We have now added it to the card account entity. It can be accessed via this endpoint GET /card-accounts.

Related transactions for statement entity

Each statement has a 1:1 relationship to account entries. It is now possible to fetch all account entries for a given statementId. We extended the existing endpoint GET /statements/{{statementId}} to fetch the details of a statement with the relatedTransaction property.

New custom names character length

We are improving our cards service adjusting the maximum characters of customFirstName and customLastName to a total of 100 (from the current 25).

This change will be especially relevant for travel consumers.

Additional payment webhook

We introduced a new webhook, PAYMENT_READY. API Reference

With this new webhook consumers will be able to identify when a bill payment is complete (= no more transactions will be added to that payment).

We introduced a new endpoint to retrieve account entries for a set organization. Account entries are basically all movements of a card account. The endpoint will enable you to fetch booked account movements and provide detailed account informations, together with the statements endpoint.

• GET /account-entries will return the movements as specified
• POST /account-entries/subscription to subscribe to the related ACCOUNT_ENTRY_CREATED event. The response payload of the callback will be the same of the GET endpoint above