Import an Exchange Contact item Graph API created an item but it is not visible in the UI

Question

Import an Exchange Contact item Graph API created an item but it is not visible in the UI

Markiian 0

I have exported items from EWS using beta MSGraph API and the following endpoint and saved "data" attribure (which is based 64 encoded prior to documentation):

/beta/admin/exchange/mailboxes/{mailbox_id}/exportItems

In the body I have passed Contact item ID, retrieved from the following request

/beta/admin/exchange/mailboxes/{mailbox_id}/folders/{Contacts folder id}/items/

After that I have deleted a Contact in the outlook UI, and removed from "deleted items"

Then I have created a restore session using the following endpoint:

/beta/admin/exchange/mailboxes/{mailbox_id}/createImportSession

And sent the request to the received importURL with the previously retrieved "data" attribure of Contact item. The body is the following:

{
    "Mode": "create",
    "FolderId": "Contacts folder ID",
    "Data": "base64_encoded_Contact_item_data_in_FTS_format"
}

I recieved 200 code and the ID, change token of newly created Contact item.
BUT The contact is not visible in the UI at all.
But when I try to list items in the Contact folder It appears there and can be exported.
What can I do with it? I believe it is a bug in MSGraph Import/Export mailbox API?
No manipulations or changes to the FTS data was made.

Markiian 0 Reputation points

2026-05-04T10:24:51.61+00:00

Because the FTS data was taken from a deleted item and re-imported via the low-level import API, there is no guarantee that the resulting item will be surfaced correctly in all clients.

The FTS data was taken from existing Contact item. Contact has been deleted after the export operation. Then for what purposes Importing items via Import session should be used?
Using Item Model endpoints (for example, Contact / CalendarItem / Message) requires additional set of permissions. EWS Import/Export API should provide general access to Fetching and Creating/Updating different item types, isn't it?
Glen Scales 4,451 Reputation points

2026-05-14T00:07:51.3233333+00:00

BUT The contact is not visible in the UI at all.

Which UI isn't it visible in, different clients can treat contacts different and it could also be that you have a synchronization issue with the particular client your using as a number of them do offline sync etc. A good test is use Outlook classic not in cache mode this ensure no caching isn't involved and it just plain old Mapi. There are some know issues in EWS where particular missing properties can cause a contact to not be visible in certain clients like Outlook on the Web, in these instances you would be able to still see the contact in Outlook classic and making a small change in Outlook would force the properties to be updated. There is also some substrate synchronization of contacts that happens these days so you could also be hitting an edge case or bug there.

1 answer

Your answer

Markiian 0 Reputation points

2026-05-04T10:24:51.61+00:00

Because the FTS data was taken from a deleted item and re-imported via the low-level import API, there is no guarantee that the resulting item will be surfaced correctly in all clients.

The FTS data was taken from existing Contact item. Contact has been deleted after the export operation. Then for what purposes Importing items via Import session should be used?
Using Item Model endpoints (for example, Contact / CalendarItem / Message) requires additional set of permissions. EWS Import/Export API should provide general access to Fetching and Creating/Updating different item types, isn't it?
Glen Scales 4,451 Reputation points

2026-05-14T00:07:51.3233333+00:00

BUT The contact is not visible in the UI at all.

Which UI isn't it visible in, different clients can treat contacts different and it could also be that you have a synchronization issue with the particular client your using as a number of them do offline sync etc. A good test is use Outlook classic not in cache mode this ensure no caching isn't involved and it just plain old Mapi. There are some know issues in EWS where particular missing properties can cause a contact to not be visible in certain clients like Outlook on the Web, in these instances you would be able to still see the contact in Outlook classic and making a small change in Outlook would force the properties to be updated. There is also some substrate synchronization of contacts that happens these days so you could also be hitting an edge case or bug there.

Answer 1

The behavior matches how Exchange import/export works: the item is being restored at the data level, but not in a way that guarantees it will surface as a normal, visible contact in Outlook.

From the documented patterns:

EWS/Exchange import is supported in three main ways:
1. Creating items via Exchange item types (recommended when importing from other systems).
2. Item-level export/import for full-fidelity copies between Exchange mailboxes.
3. MIME-based formats (iCal/vCard) for small volumes.
For full-fidelity, item-level import/export, the supported pattern is:
- Export with ExportItems (or the Graph exportItems equivalent).
- Import with UploadItems (or the corresponding import mechanism) using the exported data stream.
- The imported item is then a server-side copy of the original.

However, the documentation also makes clear that:

EWS and related APIs are not designed as a general-purpose backup/restore mechanism for arbitrary mailbox items.
When importing items from other systems or restoring items, the recommended approach is to create a new item using the item model (for example, Contact / CalendarItem / Message) and explicitly set the properties, then save it using CreateItem or Item.Save.

In this scenario:

The contact is present in the folder and can be exported, which means the import session and FTS data are valid at the store level.
The fact that Outlook UI does not show it indicates the restored item is not in a state that Outlook recognizes as a normal, visible contact (for example, missing or inconsistent schematized properties, extended properties, or flags that Outlook relies on for display).
Because the FTS data was taken from a deleted item and re-imported via the low-level import API, there is no guarantee that the resulting item will be surfaced correctly in all clients.

The supported workaround is to avoid relying on FTS-based restore for user-visible contacts and instead:

Export the contact using the item model (for example, GetItem / Contact.Bind with the desired property set).
Recreate the contact by calling CreateItem (or the equivalent Graph create-contact API) and explicitly setting the properties.
Save it into the Contacts folder so Outlook treats it as a normal contact.

For bulk or cross-system scenarios, the guidance is the same: use the item-type-based import (Contact/Message/Appointment/Task) rather than raw FTS data, unless performing a supported, full-fidelity copy between Exchange servers where the client UI behavior is validated.

Given the documentation, this is a limitation of the low-level import path rather than a supported, guaranteed UI-visible restore mechanism. The reliable path to make the contact visible again is to recreate it via the contact item model instead of re-importing the FTS data.

References: