🚧

Changes effective the 30.01

We are introducing quotas for Auth0 Access Tokens.

Enforcement

Quotas are now enforced for new API consumers upon activation.

Monitoring Usage

Specific limits vary based on account type and program requirements.

Please refer to the API response header to monitor the available tokens and remaining quota for your specific use case.

For a comprehensive breakdown of our rate-limiting logic, please visit the Access Token Request Quotas guide.

We released a change that enables consumers to subscribe to callback events with more than one url.

  1. Add Multiple Callback Subscriptions: POST /subscriptions/bulk-upsert

This creates multiple callback subscriptions in a single request; returns both newly created subscriptions and already-existing matches (same eventType + callbackUrl).

Multiple subscriptions per eventType are supported as long as callbackUrls differ.

If a subscription with the same eventType + callbackUrl already exists, it is not modified and is still included in the response.

Only the subscriptions included in the request are affected; other existing subscriptions remain unchanged.

Limit: max 42 subscriptions per event type.

  1. Delete Callback Subscription: DELETE /subscriptions/id

This deletes a callback subscription by its UUID. It respond with 204 No Content on successful deletion.

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

📘

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 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.