This article helps you get ready to bring your two current SCIM integrations — TravelPerk SCIM for travel and Yokoy SCIM for spend — together into one unified Perk SCIM integration. It explains how your current setup compares to the new model, so you can pull together accurate information about your SCIM configuration and share it with your Perk contact.

Before you start

Today, you run two separate SCIM integrations side by side: TravelPerk SCIM provisions users for travel, and Yokoy SCIM provisions users for spend and expense. Perk has unified both of these into a single Perk SCIM integration that covers travel and spend together, through one connection to your identity provider — whether that's Okta, Azure AD (Entra ID), or a custom, direct API integration. You make the actual configuration change in your identity provider yourself; Perk's team doesn't make this change on your behalf. But before you do, your Perk contact reviews your current TravelPerk SCIM and Yokoy SCIM setup and tells you exactly what to configure in Perk SCIM. This article's job is to help you understand the differences between your current setup and the new model well enough to share accurate, useful information with your Perk contact. It doesn't walk you through identity provider configuration steps directly — that guidance comes from Perk after reviewing what you share.

How your current setup compares to the new Perk SCIM

TravelPerk SCIM, your current travel-side integration, carries over into Perk SCIM almost unchanged. TravelPerk SCIM uses the SCIM core schema, the enterprise extension (urn:ietf:params:scim:schemas:extension:enterprise:2.0:User), and a custom Perk extension (urn:ietf:params:scim:schemas:extension:travelperk:2.0:User) for travel-specific fields like travelPolicy, invoiceProfiles, and lineManagerEmail. Perk SCIM keeps this same core schema, the same enterprise extension, and the same custom Perk extension, so most of your existing attribute mapping for travel doesn't need to change. The genuinely new part is the expense extension (urn:ietf:params:scim:schemas:extension:expense:2.0:User). TravelPerk SCIM never had this extension, because expense management wasn't part of it. Perk SCIM adds it specifically to cover everything your Yokoy SCIM integration currently handles for spend — things like expense policies, legal entities, and approval thresholds. Perk's expense extension is built on the same underlying logic as Yokoy's own custom extension — it's the same idea, carried over as part of Perk's platform. That's why the attribute names in the expense extension will look familiar if you've configured Yokoy SCIM before: policyId, creditor, legalEntityId, approvalThreshold, and ignoreManagerInRequests all reappear with the same names and the same concepts.

Share your current SCIM payloads

Sharing your current SCIM payloads is how Perk gathers accurate information about your setup before telling you what to configure. Before you or Perk's team decides on anything, Perk needs to see exactly what your identity provider currently sends to both TravelPerk SCIM and Yokoy SCIM.

Here's how the process works:

1. Export or document the SCIM payload your identity provider currently sends to TravelPerk SCIM.
2. Export or document the SCIM payload your identity provider currently sends to Yokoy SCIM.
3. Share both payloads with your Perk contact.
4. Perk's team reviews your payloads and sends back the exact values and attribute mapping to use in Perk SCIM, along with any changes you need to make in your identity provider.

This is a data-gathering step, not a configuration step. You're not deciding final values on your own here — you're giving Perk accurate ground truth about your current setup so their team can tell you exactly what to use.

Attribute comparison: Yokoy SCIM and the Perk expense extension

The Perk expense extension covers the same ground as your current Yokoy SCIM integration, so it helps to see the two side by side. Use this table to check your current Yokoy attributes against their closest Perk SCIM equivalents when you document your Yokoy payload for Perk.

Cost objects, policies, and managers

A few attributes in the table above need more context before you describe them accurately to Perk, because the mapping isn't purely mechanical. Cost objects. Yokoy's costCenter field sends cost object codes that must already exist in Yokoy before you provision a user with a value — Yokoy doesn't create cost objects from SCIM data automatically. Perk auto-creates a cost object, such as "Marketing," if it doesn't already exist. Expense policy vs. travel policy. Yokoy's policyId links a user to an expense policy. Perk SCIM keeps this as policyId in the expense extension, but Perk also has a separate travelPolicy field in its custom Perk extension, which must already exist in Perk and covers travel policy specifically. These are two different fields covering two different areas. If your organization uses both, document both values when you share your payload with Perk. Managers and approvers. In Yokoy, manager.value is ID-based, and the user's line manager automatically becomes their approver — Yokoy's enterprise schema has no separate approver concept. If a manager doesn't exist yet in Yokoy, a stub user is created for them, and anyone with no manager, such as a CEO, must be set as their own line manager. Perk SCIM gives you two ways to assign a manager: manager.value (by Perk user ID) or lineManagerEmail (by email, built for identity providers like Okta that can't reference users by internal ID). When you share your setup with Perk, describe which of these your identity provider can support, so Perk configures the right one.

Key considerations

Keep these points in mind as you prepare your payloads for Perk.

Organization

The organization attribute is a required, constant Yokoy identifier for the user's organization, copied once from the Yokoy admin UI and reused for every user. In Perk, your account isn't identified by an attribute in the payload at all, it's implicit in which base URL and API key you're using.

User language

Yokoy combines language and locale into a single preferredLanguage field, for example de-ch. Perk SCIM splits this into two fields: preferredLanguage for the language itself, and a separate locale field, used only at creation, that Perk splits on the hyphen or underscore to work out country and currency. Document both parts separately when you share your Yokoy preferredLanguage values with Perk.

Custom fields

The Yokoy SCIM schema offered the possibility of creating custom fields directly in the User form with customData0–customData3, each requiring a matching custom field, such as data0. Perk SCIM has no direct equivalent. If your organization relies on these fields today, flag this as a gap when you share your payload with Perk.

What happens next

Once you've shared your payloads and Perk's team has reviewed them, the switch happens in three stages:

• Day before SCIM trial. You disable Yokoy's SCIM and update your TravelPerk SCIM configuration, following Perk's guidance. Yokoy keeps working as normal, since Perk syncs both systems in the background.
• Day of the changeover. Perk grants trial access to the unified setup. Yokoy keeps working in parallel.
• Two weeks after the changeover. Perk cuts off Yokoy access. You're fully onboarded to Perk Travel & Spend with one SCIM integration.