API Field Naming Convention - Need Verification

Hi everyone,

I’m currently building a Model Context Protocol (MCP) server to integrate with Manager.io, and I’ve discovered something about the API that I’d like to verify with the community.

Background: My MCP server communicates with the API2 endpoint. I’ve been debugging why create/update operations weren’t working correctly for certain objects, and I’ve traced it to what appears to be inconsistent field naming requirements.

My Findings:

For objects like Receipts and Payments that have nested line items, the API seems to require different casing depending on the field location:

  1. Main object fields: Must use PascalCase

    • Example: Date, ReceivedIn, Reference, Amount
    • Using camelCase (e.g., date, receivedIn) causes those fields to be ignored
  2. Line item fields: Must use camelCase

    • Example: account, amount (not Account, Amount)
    • Using PascalCase for line items also causes them to be ignored

I’ve tested this with Receipts specifically:

  • Input: {"Date": "...", "ReceivedIn": "...", "Lines": [{"account": "...", "amount": 100}]}Works
  • Input: {"date": "...", "receivedIn": "...", "Lines": [{"Account": "...", "Amount": 100}]}Fields ignored

Questions for the community:

  1. Is this the expected behavior across all endpoints, or is this specific to Receipts/Payments?
  2. Is this documented anywhere? I haven’t found it in the API documentation.
  3. Are there other endpoints with similar behavior I should be aware of?

Any insights or confirmation would be greatly appreciated!

Thanks,
Brian

Hello @SpiffyStores,

Welcome to the forum.

Yes, you should visit https://{ your manager domain }/api2 and this should give you the schema in .json format.

and

I have never thought of this before and I cannot say that I have gone through all endpoints, but all endpoints do share the same case conventions as far as I can tell.

One peculiarity that I can point out is that for Bank and Cash Accounts, the endpoint for posting single form is /bank-or-cash-account-form – which is grammatically correct but got me going around in circles the first time I came accross it.

Thanks for the reply!

Yes, I started with the schema to map out the tool set I needed for the MCP. I discovered that neither the schema nor the API documentation list the fields required for any object, and that’s the problem.

At the moment, I’m in the process of mapping it all through scripts to discover the exact field requirements, which is where I came across the CamelCase versus PascalCase naming confusion.

I’m hoping someone has already found the definitive answer to this.

As far as I can tell, all transactional objects share the same line fields with the exception of Payslips.

Ok, here’s an update on the field naming conventions I discovered through testing:

  • Create/Update: POST/PUT to `/receipt-form` require PascalCase fields
  • List/Search: GET `/receipts` and `/receipt-lines` return camelCase
  • Get by Key: GET `/receipt-form/{key}` returns PascalCase + includes a “Lines” array with associated line items

Make sure to use PascalCase when creating or updating records, or fields will be ignored.

1 Like