This is one of those MYOB Advanced API issues that looks confusing at first.
You can see the data inside MYOB Advanced. Companies are there. Financial Periods are there. The screens are available in the UI.
But when you try to access the same data from the REST API, it is not available through the default endpoint.
That does not always mean the data cannot be accessed.
It usually means the default Web Service Endpoint is not exposing it.
MYOB Advanced uses Web Service Endpoints to decide which screens, entities, fields, and actions are available through the REST API. The standard endpoint covers common records like customers, vendors, inventory items, and sales orders, but it does not expose every screen or every field by default.
So if your integration needs Companies, Financial Periods, or custom screen data, you may need to extend the endpoint.
The mistake developers often make
When data is missing from the default REST API, the first reaction is usually to search for the right object name.
Maybe it is called Company.
Maybe it is called Companies.
Maybe it is under the financial setup.
Maybe it needs $expand.
But sometimes the object is not missing because of the query.
It is missing because it was never exposed in the endpoint.
That is the main point.
In MYOB Advanced, the endpoint works almost like an API contract. If an entity or field is not part of that contract, the API will not return it even if the data exists inside the system.
Default endpoint vs custom endpoint
Here is the simple difference:
Default endpoint
Standard records like customers, vendors, inventory, sales orders
Custom / extended endpoint
Missing screens, custom fields, Companies, Financial Periods, company-specific financial data
If your integration only needs standard business objects, the default endpoint may be enough.
But if the workflow needs setup-level data or financial period details, the better option is usually to extend the endpoint instead of building workarounds.
Exposing Companies through API
For Companies, the endpoint needs to be extended from the Web Service Endpoints screen.
The original Satva guide uses this screen for Companies:
CS101500
The rough flow is:
Open Web Service Endpoints.
Extend the existing endpoint.
Add a new entity for Companies.
Map it to screen CS101500.
Populate fields.
Save the endpoint.
Test the API.
After setup, the test call may look like this:
GET {{baseURL}}/{{endpoint}}/Companies
If everything is mapped properly, the API should start returning Companies data.
Small note: if the entity does not show up, check the endpoint name, version, screen mapping, and whether the endpoint was saved after adding the entity.
Financial Periods need the same treatment
Financial Period data is also not available through the standard REST endpoint in the usual setup.
So if your integration needs period details, closing period logic, reporting periods, or company-specific calendar data, you need to add Financial Period as a custom entity.
The call may look like:
`GET {{baseURL}}/{{endpoint}}/FinancialPeriod?$expand=Details
The important part is not just the API URL.
The entity must first be added to the custom endpoint. Without that, the API call will not magically return the data.
One setting that can change the result
Before spending too much time debugging Financial Period responses, check Centralized Period Management.
This setting changes how financial periods behave in MYOB Advanced.
Centralized Period Management ON
All companies share the same financial periods
Centralized Period Management OFF
Each company can manage its own financial periods
When centralized period management is enabled, company-level filtering may not work as expected because periods are handled globally. When it is disabled, company-specific financial period operations become possible.
So if your API response is not filtering by company, the endpoint may not be the only issue. The system configuration may be affecting the behavior.
Quick troubleshooting notes
- Entity is not visible in API - Endpoint saved or not
- API URL returns error - Endpoint name, version, entity name
- Fields are missing - Use Populate under the Fields tab
- Custom field not returned - Check if customization package is published
- Financial Period not filtering by company - Check Centralized Period Management
- Empty response - Screen mapping and user access
Most of these issues are not API bugs. They usually come from endpoint setup, field mapping, permissions, or configuration.
When custom endpoints are worth it
Custom endpoints are useful when the default REST API does not match the integration requirement.
For example:
You need the company's data.
You need Financial Period data.
You need custom fields.
You need data from a screen that is not exposed by default.
You need company-specific financial calendar behavior.
You want the API response to match your external system’s workflow.
For simple integrations, custom endpoints may not be necessary.
But once the required data is outside the default endpoint, extending the endpoint is usually cleaner than creating complex workarounds.
What to remember
If Companies or Financial Periods are visible inside MYOB Advanced but missing from the REST API, do not assume the data is unavailable.
First, check whether the endpoint exposes it.
For Companies, map the Companies screen.
For Financial Periods, add Financial Period as a custom entity.
For company-specific period behavior, check Centralized Period Management.
In short:
The data may already exist in MYOB Advanced.
The API just needs to be told to expose it.
Originally published on Satva Solutions:
MYOB Advanced API Custom Endpoints Guide
https://satvasolutions.com/blog/myob-advanced-expose-custom-web-service-endpoints
Top comments (0)