13 recommendations for using the Eulerian reporting API

13 recommendations for using the Eulerian reporting API



1. Key principle of the Batch Reporting API

The Batch Reporting API allows you to extract Eulerian reporting data from the views available in the interface.
It should be used as a means of automating the extraction of reports already available in the Eulerian interface. It should not be considered a tool for creating, in a single query, a level of granularity or a combination of data that does not exist in the reports.
For example, if an analysis requires combining multiple sources or views, multiple API requests must be made, and then the results must be aggregated on the BI side, data warehouse, or processing script.


2. Recommended time to launch API jobs

To retrieve the complete data from J-1, it is recommended to start the exports from 06:00 am .
During the night, Eulerian synchronizes the cold database to integrate the data from the previous day. A very early morning query, for example around 05:00, may fall during this synchronization and encounter unavailability or return incomplete data.
The operational recommendation is therefore to schedule API jobs from 06:00 onwards.


3. Retrieve the correct parameters for an API request

A simple method for building an API request is to start with the desired report in the Eulerian interface, and then observe the request generated by the interface.
Recommended steps:
    Open the desired report in the Eulerian interface.
    Open the browser's developer tools with F12 .
    Go to the Network tab.
    Identify the reporting query generated by the interface.
    Retrieve the parameters needed to build the API body.
The useful items to retrieve include:
Élément observé dans la requête réseau
Utilisation dans l’API
view-id
Attribution view ID
ea-datasource
Value of the kind , with the prefix rt# in the API body
path
Value to use in the path field of the JSON body
IDs present in the path
Publisher IDs, leverage, media plan or campaign depending on the view viewed
The path visible in the console already contains the IDs corresponding to the data level being viewed: publisher, lever, media plan, campaign, etc.


4. Query Endpoint

The endpoint used to query the Batch Reporting API is of the form:
POST /ea/{site}/report/{batch}/query.json
The JSON body typically contains an array
Content-Type: application/json
reports , in which we define:
Élément
Rôle
dateRanges
Analysis period
dimensions
Key points to consider in the report
kind
Data source / report type
metrics
Indicators to extract
path
Media reporting level or scope
segmentFilterClauses
Optional filters, for example on sales types
Simple example:
 {
 "reports": [
 {
 "dateRanges": [
 {
 "range": "YESTERDAY"
 }
 ],
 "dimensions": [
 {
 "field": "ope_name",
 "name": "campaign"
 }
 ],
 "kind": "rt#insummary",
 "metrics": [
 {
 "field": "scartvalid",
 "name": "sales"
 }
 ],
 "path": "mcMEDIAINCOMING[?].mcMEDIAAD.mcOPE"
 }
 ]
THE
}

kind , path , dimensions and metrics must be adapted to the ratio that we wish to reproduce.


5. Filter by sales type

Filters on sales types are managed via segmentFilterClauses .
In the case of sales types, the field to use is:
 Example of a query with a filter on the type of sale:
"field": "ordertype_id"

{
  "reports": [
    {
      "dateRanges": [
        {
          "range": "YESTERDAY"
        }
      ],
      "dimensions": [
        {
          "field": "ope_name",
          "name": "campaign"
        }
      ],
      "kind": "rt#insummary",
      "metrics": [
        {
          "field": "scartvalid",
          "name": "sales"
        }
      ],
      "path": "mcMEDIAINCOMING[?].mcMEDIAAD.mcOPE",
      "segmentFilterClauses": [
        {
          "field": "ordertype_id",
          "operator": "IN",
          "value": [
            1,
            2
          ]
        }
      ]
    }
  ]
}


Les IDs à renseigner dans value doivent être récupérés dans l’interface Eulerian via la recherche Liste des types de ventes.
À retenir : il ne faut pas utiliser directement le libellé métier du type de vente dans la requête API. Il faut utiliser son ID technique.


6. Récupérer les IDs des types de ventes

Pour récupérer les IDs des types de ventes :
    Aller dans l’interface Eulerian.
    Utiliser la barre de recherche en haut à droite.
    Rechercher Liste des types de ventes.
    Identifier les IDs correspondant aux types de ventes souhaités.
    Utiliser ces IDs dans segmentFilterClauses.value.
Exemple :
"segmentFilterClauses": [
  {
    "field": "ordertype_id",
    "operator": "IN",
    "value": [
      117,
      135,
      159
    ]
  }
]


Les valeurs ci-dessus sont données à titre d’exemple. Elles doivent être adaptées au périmètre client et aux types de ventes réellement visibles dans l’interface.


7. IDs des leviers média Eulerian

Les principaux IDs de leviers média sont les suivants :
ID
Levier
2
MAILING
3
ADVERTISING / Display
4
AFFILIATION
5
SPONSOREDLINK / Liens sponsorisés
6
PARTNER / Partenariat
7
INTERNAL
8
TRUSTEDFEED
10
BRANDING
16
OFFLINE
17
SOCIAL
20
GENERIC
These IDs can be used to check or build path related to media views.


8. Augmented attribution model IDs

For attribution algorithms, the IDs are visible in the Eulerian interface, via the Create and edit my models page.
This will allow you to identify the attribution model used in the reporting views.


9. Best practices for BI/Data Warehouse integration

To industrialize the use of the Eulerian reporting API, it is recommended to:
  • starting from an existing view in the Eulerian interface to build the API request;
  • retrieve the kind , path and IDs via the Network tab of the browser;
  • schedule API calls starting from 06:00;
  • use technical IDs rather than business labels;
  • use segmentFilterClauses to apply specific filters;
  • execute multiple queries when the desired view combines multiple perimeters;
  • aggregate the results on the BI side, data warehouse or processing script;
  • retain an extraction timestamp to facilitate data auditing.


10. Operational Summary

Sujet
Recommandation
Endpoint
POST /ea/{site}/report/{batch}/query.json
Format
JSON
Recommended launch time
Starting at 6:00 AM
Query construction
Starting from an existing view in the interface
Retrieving the kind and path
Via the browser's Network tab
Sales type filter
segmentFilterClauses with field: "ordertype_id"
Sales type IDs
To be retrieved from the list of sales types
Media lever IDs
Use this to check the path
Augmented MTA model IDs
Via the Template Creation and Editing page
complex aggregation
Make multiple queries and then aggregate them on the BI side.


11. How to request media plans

To query media plans via the Eulerian reporting API, it is recommended to split the query into several parts so that it remains viable and usable.
The best practice includes performing a query for each acquisition channel.
Each request follows the same structure, but with a different path depending on the desired lever.
Levier d’acquisition
Path à utiliser
Display
mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[3].mcPUBLISHER
Mailing
mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[2].mcPUBLISHER
Social
mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[17].mcPUBLISHER
SEA
mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[5].mcPUBLISHER
Affiliation
mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[4].mcPUBLISHER
In these examples:
  • mcWEBSITE[1] corresponds to the site in question;
  • mcMEDIAPLAN[1] corresponds to the targeted media plan;
  • mcMEDIA[x] corresponds to the acquisition lever;
  • mcPUBLISHER allows you to go down to the support/publisher level.
IDs must be adapted to the client context and the desired level of reporting.

Example query for the Display lever

Example for the Display lever, with attribution views 3 , 8 and 6 , over the period from 01/04/2026 to 31/05/2026 .
 {
 "async": false,
 "reports": [
 {
 "kind": "rt#mediaplan",
 "path": "mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[3].mcPUBLISHER",
 "segments": [
 {
 "name": "Attribution rule",
 "operator": "IN",
 "type": "attributionrule",
 "value": [
 3,
 8,
 6
 ]
 }
 ],
 "dimensions": [
 {
 "field": "publisheralias_alias",
 "name": "Support"
 }
 ],
 "metrics": [
 {
 "name": "Ventes réelles",
 "field": "realscartvalid"
 }
 ],
 "dateRanges": [
 {
 "dateFrom": "2026-04-01",
 "dateTo": "2026-05-31",
 "dateFormat": "YYYY-MM-DD"
 }
 ]
 }
 ]
To query another lever, simply use the same structure and replace the value of the
}

path by that of the desired lever.
For example, for SEA, the path becomes:
 This approach helps to secure response times, better control the volumes returned and facilitate the aggregation of results on the BI or data warehouse side.
"path": "mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[5].mcPUBLISHER"



12. Recommendation: choose between publisheralias_alias and publisher_name

During a query, it may happen that the publisheralias_alias dimension returns an empty value even though metrics are present.
This behavior is normal and depends on how Eulerian tracking has been implemented on partner platforms.

Difference between publisheralias_alias and publisher_name

When Eulerian tracking is implemented within a third-party platform such as a DSP, ad server, or media platform, campaign tracking parameters do not directly collect the publisher or campaign name via a readable macro, for example:
 In this case, tracking can be powered by technical IDs, for example:
ead-publisher={{publisher_name}}, qui deviendrait "lequipe.fr"

 Eulerian then uses EPC connectors to map the ID collected in the tracking settings to the actual publisher or campaign label as it appears in the third-party platform.
ead-publisher={{publisher_id}}, qui deviendrait "1234"

These revised labels are called aliases on the Eulerian side. They are accessible via the dimension:
 {
 "field": "publisheralias_alias",
 "name": "Support"
Conversely, when the publisher's name is sent directly to the tracking, without requiring connector mapping, the following dimension must be used:
}

 {
 "field": "publisher_name",
 "name": "Support"
13. Use
}


overwriteNameByAlias ​​to automatically manage aliases

To avoid having to manually switch between publisher_name and publisheralias_alias , you can use the following API option:
 This option allows you to ask the API to prioritize the alias when it exists, while keeping the raw name when the alias is not available.
"overwriteNameByAlias": true

It specifically addresses the following case:
  • If the publisher has an alias, the API returns the alias;
  • If the publisher does not have an alias, the API returns the publisher_name .
This helps to limit empty lines in exports and to obtain a “Support” dimension that is more directly usable on the BI or data warehouse side.

Where to place the option in the query

The overwriteNameByAlias ​​option must be added at the report block level, at the same level as kind , path , segments , dimensions , metrics and dateRanges .
Example on the social lever:
{
  "async": false,
  "reports": [
    {
      "kind": "rt#mediaplan",
      "path": "mcWEBSITE[1].mcGLOBALMEDIAPLAN.mcMEDIAPLAN[1].mcMEDIA[17].mcPUBLISHER",
      "overwriteNameByAlias": true,
      "segments": [
        {
          "name": "Attribution rule",
          "operator": "IN",
          "type": "attributionrule",
          "value": [
            3,
            8,
            6
          ]
        }
      ],
      "dimensions": [
        {
          "field": "publisher_name",
          "name": "Support"
        }
      ],
      "metrics": [
        {
          "name": "Ventes réelles",
          "field": "realscartvalid"
        }
      ],
      "dateRanges": [
        {
          "dateFrom": "2026-04-01",
          "dateTo": "2026-05-31",
          "dateFormat": "YYYY-MM-DD"
        }
      ]
    }
  ]
}



Dimension à utiliser avec cette option

Lorsque overwriteNameByAlias est activé, il est recommandé d’utiliser la dimension standard publisher_name :
"dimensions": [
  {
    "field": "publisher_name",
    "name": "Support"
  }
]

L’API se charge alors d’appliquer l’alias lorsque celui-ci est disponible.
Cette approche est plus simple que de requêter séparément publisher_name et publisheralias_alias, puis de réconcilier les deux champs côté BI.

Portée de l’option

L’option overwriteNameByAlias ne s’applique pas uniquement aux publishers.
Elle peut également s’appliquer aux autres dimensions disposant d’un mécanisme d’alias, par exemple :
Dimension brute
Alias potentiellement appliqué
publisher_name
publisher alias
ope_name
campaign alias
creative_name
alias for creation
This option therefore allows for cleaner and more consistent labels in API exports when Eulerian connectors feed aliases.

Operational recommendation

For queries by support/publisher:
    Use publisher_name as the primary dimension.
    Add "overwriteNameByAlias": true in the report block.
    Test the result on the levers where the two logics coexist, particularly Social.
    Keep this option if the supports are correctly retrieved with the expected aliases and without unjustified empty lines.
This option is particularly useful for the Social lever, where some campaigns can be tracked via partner IDs and then reprocessed by alias, while other campaigns can be tracked manually with an already available publisher name.