Al: Extend API fields

[Mr-Pingu]

It's sad you can't extend API pages, I would like to integrate a more advanced sync between our webshop and BC for items. However some fields aren't available through the API I would like to extend the API to get more Item fields visible to the API.

I can ofcourse create a new API page and add the fields I want but that leaves me with different endpoints for different fields or I have to define all the fields from the current API to the new page.

I wish there is a better way to extend the API pages than the current solution I proposed above

[Mr-Pingu]

Seems it can....

The page does say I shouldn't extend an API page, why?
"The API page type should not be extended by creating a page extension object. Instead, create a new API by adding a page object."

I could easily extend the API-page "Customer Entity" with the following code:

pageextension 50136 CustomerAPIext extends "Customer Entity"
{
    layout
    {
        addafter(shipmentMethodId)
        {
            field("CustomerDiscGroup"; "Customer Disc. Group")
            {

            }
        }
    }
}

When I try to to request the api url like specified in the documentation, the field is available for acces.

{
    "@odata.context": "https://api.businesscentral.dynamics.com/v1.0/<Tenant-ID>/sandbox/api/beta/$metadata#companies(<Company-id>)/customers/$entity",
    "@odata.etag": "W/\"JzQ0O2RIRUVHMHFPWUEyQ0VSOUdyQzNjaUNlcEpXbUpSN3o4Q0QySmE2VnVId1U9MTswMDsn\"",
    "id": "ee09031b-fdba-4b29-8500-031b5777ab98",
    "number": "0001",
    "displayName": "Name Name",
    "type": "Company",
    "phoneNumber": "0",
    "email": "",
    "website": "",
    "taxLiable": false,
    "taxAreaId": "00000000-0000-0000-0000-000000000000",
    "taxAreaDisplayName": "",
    "taxRegistrationNumber": "",
    "currencyId": "00000000-0000-0000-0000-000000000000",
    "currencyCode": "EUR",
    "paymentTermsId": "00000000-0000-0000-0000-000000000000",
    "shipmentMethodId": "00000000-0000-0000-0000-000000000000",
    "CustomerDiscGroup": "",
    "paymentMethodId": "00000000-0000-0000-0000-000000000000",
    "blocked": " ",
    "balance": 0,
    "overdueAmount": 0,
    "totalSalesExcludingTax": 0,
    "lastModifiedDateTime": "2019-01-09T14:30:22.47Z",
    "address": {
        "street": "",
        "city": "",
        "state": "",
        "countryLetterCode": "",
        "postalCode": ""
    }
}

So why is this important?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: cdda7e30-30d9-ac83-abf7-267a7f634c6d
• Version Independent ID: 5bf5ce87-f59a-d2ae-10b3-05eda02406b5
• Content: Page Extension Object - Business Central
• Content Source: dev-itpro/developer/devenv-page-ext-object.md
• Service: dynamics365-business-central
• GitHub Login: @SusanneWindfeldPedersen
• Microsoft Alias: solsen

[henrikwh]

Hi,
This its true that you should not extent the 'Standard' API pages. Its prevented in upcoming release.
If you need additional attributes, you have to create your own APIs (in a namespace which indicates that the API is for your ecommerce solution).
Design criteria for the Standard APIs is to keep them versioned so integrators have a fixed versioned contract.

[Mr-Pingu]

@henrikwh Thanks for the clarification.
So I just should copy the API-page from the AL source and then modify it to my likings and use my own namespace?

For my E-commerce solution I need to have some more fields exposed, where can I find what the roadmap is for the API? What kind of fields and tables will become available next couple of releases?

[henrikwh]

@Mr-Pingu Yes. The you own the API and can do whatever you need to do, and version it accordingly to match your integration needs.
We are about to publish the release notes for april. For APIs this means that apis will move out of beta in into V1.0. There will be some improvements regarding deeper linking of entities, removal of multipart keys, and an API for employee timesheets.

Specific entities and attribute additions are handle by request, where it supports a broader scenario. Feel free to mail me.

[Mr-Pingu]

@henrikwh Thanks again for the clear words. I will wait patiently for the release notes. When do you expect them to be published?

Regarding for specific entities and attributes for this I will write you an e-mail. In my opinion there are multiple fields / entities missing but the most prominent is the ship-to part on an Sales-order. For us, running an e-shop, it's very common to ship the products to another adress with regards to the invoice address. For example if a customer wants to want it delivered on work but the invoice has to be sent to his home.

[podgaard]

Hi guys!

I am in same situation needing more fields in Sales Order API. I am going live with a customer solution in April with roughly 500 daily orders, and together with e-commerce partner we are dedicated to keep as much as possible standard in the integration part - like we should.

Perhaps Mr-Pingu already requested the same information in his e-mail, but from my view we severely lack these fields in the standard Sales order API.

"Payment Method" - Need to have
"Global Dimension 1 Code" - Need to have
"Global Dimension 2 Code" - Need to have
"Shipping Method" - Need to have
"Shipping Address" - Need to have
"Your Reference" - Need to have
"Location Code" - Need to have
"Work Description" - Nice to have
"Order Class" - Nice to have

Furthermore - on the Sales Order Lines, variant-code is lacking. This is a "Need to have".

Without these, I need probably to make multiple silly work around if we want to keep within standard API, so is there any hope for me ?

I checked april notes, I can't see any upcoming changes, so I guess this post is a request.

https://docs.microsoft.com/en-us/business-applications-release-notes/April19/dynamics365-business-central/standard-web-apis

Thanks.

[JohanStenberg100]

Hi @podgaard, as I understand you want us to extend the standard API with these fields. Please file an idea (https://aka.ms/BusinessCentralideas) instead and we'll take a look. This is not related to AL in particular but Business Central in general.

Thanks!

Johan

[podgaard]

Hi Johan - thanks for feedback, I have now added this as an idea and I hope someone will look at this in the near future. I notice one present idea on the matter - only "Shipping Address" so far. So I added a new asking for much more :)

So if any other partners searching here, please help support by upvoting this idea.

https://experience.dynamics.com/ideas/idea/?ideaid=5d14435f-4731-e911-9461-0003ff68cf1c

[sonicadv27]

What's the reasoning behind this design?

Doesn't this defeat the whole purpose of extensibility? Why not just let partners extend the standard APIs so that standard entities have a single entrypoint?

[AlNoes]

Will there be a way in the future to get our new custom API pages in MS Flow & PowerApps connectors? Currently, I can only see the standard pages...

[henrikwh]

Hi @AlNoes
Its on the backlog, but not in scope, to have Custom APIs show in the connector. Currently you would need to create a custom connector to expose your custom APIs to Power suite.

But please vote for the idea here.

[JeremyVyska]

Hey @henrikwh - related issue, and you said feel free to email.

So, with Page Type of API, you can't do a page extension. That seems like a reasonable POV because of the fact that the API is supposed to be a contract specific data source.

Problem is, when you're then going "ok, I need custom fields in the Sales Invoice API page, I'll be a good egg and just copy the Sales Invoice API Page from base". It contains a dozen calls that we're not allowed to use in Extension development. I can't even just 'wrap' the normal Sales Invoice Entity because some of the DotNet variables involved are the parameters, as well as some of the function calls are local.

How are we supposed to handle custom fields on a Sales Invoice in the API space? The only thing I've been able to figure out is that we'll have to use a custom API copy that has none of the functions (Send, Cancel, Post) that has all of the new fields, plus an extensive amount of changes to how the Sales Invoice Aggregate table gets populated/maintained. Then, if any functions are needed, the integration developer will just have to call the base API for just the functions.

[henrikwh]

Hi @update-jeremy
Thanks for your feedback. We have work in progress, which will remove the dependencies to internal methods. That should make it possible for you to customize. I dont have a ETA yet. But, if you have access to the insider builds, you should be helped already - only a few bound actions missing refactoring.

For extending Sales Invoice, you're right. You need to handle the the fields you add. But it has nothing to do with the APIs.