Finance | Project Operations, Human Resources, ...

Identification of source of OData call

(1) Share

Report

Posted on by MS-29011540-0

439

Hello all.
I hope you all are doing well.
Is there a way by x++ code to identify whether a call to the data entity exposed Odata API from “open in excel” functionality or from a regular API call by an outside application?

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (6)

Answers (0)

Sort by

Martin Dráb 240,349 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

I don't believe there is.
What's the business problem that you're trying to solve by using different logic for identical API requests, just sent by different API clients?

Was this reply helpful? Yes No
Subra 2,002 Super User 2026 Season 2 on at

Like (0)

Report
Copy link

Link copied!

Hi @MS-29011540-0

I don't think we have any option to identify the source of API call. Are you looking for any specific API's?

Was this reply helpful? Yes No
MS-29011540-0 439 on at

Like (0)

Report
Copy link

Link copied!

@Martin Dráb
There a requirement to stop requests to a specific API but at the same time they want to take the advantage of the Odata.
The API contains critical information in their openion don't want to expose to any other client.
There justification is that open in excel will need a user login but any other client will need client ID/ Client Secret

Was this reply helpful? Yes No
Suggested answer

SajeedMullaji 380 on at

Like (2)

Report
Copy link

Link copied!

@MS-29011540-0
No, there is no officially supported way in X++ to differentiate between an OData call from Open in Excel versus an external API call.
Both routes hit the same /data/ OData endpoint using the Microsoft Dynamics Office Add-in and standard OAuth/Entra ID authentication. X++ session introspection classes like xSession or SysHttpHeaders do not expose a distinct flag or user-agent string that safely isolates the Excel Add-in from a Postman or external C# application using the same credentials.
Two practical workarounds if you need source tracking:
1) Expose a Custom Service endpoint using [SysODataActionAttribute] for your external integration — design the contract to include an explicit tracking parameter your external app passes. The Open in Excel path will never hit this endpoint.
2) Use a separate dedicated data entity mapped exclusively for the external integration versus the one exposed for Open in Excel — this gives you entity-level differentiation in your logs.
Hope this helps.

1 people found this reply helpful.

Was this reply helpful? Yes No
Martin Dráb 240,349 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

You're saying that the requirement is to block access to a specific API, but your further description suggests that it's actually about a particular authentication mechanism. Please elaborate what exactly they want to achieve.

Authentication and authorization is something that happens before the access to a data entity is granted, therefore it's not what you should address in X++ code inside the entity.

If they want the entity to be used for integration but not by normal users, they can handle it in F&O by granting appropriate permissions.

Was this reply helpful? Yes No
Martin Dráb 240,349 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

@SajeedMullaji Let me correct your first suggestion. A custom service isn't created with SysODataAction attribute - that's an OData action. By the way, the obvious problem is that you couldn't then use normal capabilities of OData document manipulation and you'd have to redesign the integration.

Also, you don't explain in your other suggestion how you'd map [the data entity] exclusively for the external integration. This is actually MS-29011540-0's question. My answer is that you'd have to configure permissions accordingly (e.g. giving permissions just to the accounts for integration), but you can do that with a single entity too, can't you? So it seems to me that this suggestion doesn't really address the question.

Was this reply helpful? Yes No