Multiple "Validation error of type FiledUndefined" when running example

[catogtp]

Windows running node v26.1.0
Running example code in .mjs file and receiving "return new SuperOpsError" along with validation error messages. Again, could me being green with ES and how typescript works, but I wanted to raise the issue if it's not just me. I've included the .mjs with the example code I am using and a .txt with errors.

superops-wyre-error.txt
test-wyre-superops.mjs.txt

[asachs01]

Thanks for the detailed report — and the example file plus error log made this easy to pin down. This is a real bug on our end, not anything to do with you being new to ES modules; your code is a straight copy of our README example.

The root cause: the SDK's built-in GraphQL queries request fields and arguments that don't match SuperOps' actual GraphQL schema. The server is correctly rejecting them — e.g. getAsset actually takes an input argument (not id), and several Asset fields the SDK selects don't exist on the real type.

Our test suite mocks the GraphQL responses against the SDK's own (incorrect) assumptions, which is why this slipped through — the tests never hit the real API.

We're working on correcting the queries and types against SuperOps' published API schema, and will also rework the test mocks so this can't regress. I'll update this issue when a fix ships. Appreciate your patience.

[catogtp]

We're working on correcting the queries and types against SuperOps' published API schema, and will also rework the test mocks so this can't regress. I'll update this issue when a fix ships. Appreciate your patience.

Excellent! I've actually noticed the same thing trying to write my own mini module to create tickets and add comments. Ran into similar errors and realized that some of things that are not marked as mandatory, are actually mandatory as well as some inconsistent arguments.

Sorry to add to your workload!

[asachs01]

Update — a fix for the assets resource is up in #8.

What it does:

• client.assets.get('asset-123') now sends the correct query (getAsset(input: { assetId })) and selects fields that actually exist on SuperOps' Asset type.
• assets.list() / listAll() now use SuperOps' page-based pagination.

What changed in usage (the API is now correct, so it's slightly different):

• The asset's ID field is assetId (not id).
• assets.list({ page, pageSize }) returns { items, meta } instead of cursor edges.
• assets.create() / assets.delete() were removed — SuperOps' API doesn't expose those.

Heads-up: this only fixes assets so far. The other resources (tickets, clients, etc.) have the same underlying problem and are tracked for migration in #7 — so please hold off on those for now. The README and SCHEMA.md note which resources are verified.

I'll comment again once #8 merges and a release is published. Thanks again for the report — it surfaced a genuine, SDK-wide issue.